Date: Wed, 23 Sep 2020 10:04:41 -0500 From: Kyle Evans <kevans@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Ravi Pokala <rpokala@freebsd.org>, Ed Maste <emaste@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r365846 - head Message-ID: <CACNAnaEfWeDr3peXYSd8LrQEunxVQuVOrEdCUizfsO-j5%2BaotA@mail.gmail.com> In-Reply-To: <CANCZdfqekBkhF-S%2BsxfjUk0vaNNi-WL=4c_jhGRj=dLtkjU%2BMA@mail.gmail.com> References: <202009171847.08HIlNXa015641@repo.freebsd.org> <F9E063CD-A822-481F-81B5-80DB48FE695A@panasas.com> <CACNAnaHh2hZ14%2BniJVYCSs_RDuJ=f_WSisFkNzZcjMXsCKp2XA@mail.gmail.com> <CANCZdfqekBkhF-S%2BsxfjUk0vaNNi-WL=4c_jhGRj=dLtkjU%2BMA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 23, 2020 at 9:30 AM Warner Losh <imp@bsdimp.com> wrote: > On Wed, Sep 23, 2020, 7:21 AM Kyle Evans <kevans@freebsd.org> wrote: >> >> On Mon, Sep 21, 2020 at 7:23 PM Ravi Pokala <rpokala@freebsd.org> wrote: >> > >> > -----Original Message----- >> > From: <owner-src-committers@freebsd.org> on behalf of Ed Maste <emaste= @FreeBSD.org> >> > Date: 2020-09-17, Thursday at 11:47 >> > To: <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, <svn-src-= head@freebsd.org> >> > Subject: svn commit: r365846 - head >> > >> > Author: emaste >> > Date: Thu Sep 17 18:47:23 2020 >> > New Revision: 365846 >> > URL: https://svnweb.freebsd.org/changeset/base/365846 >> > >> > Log: >> > Cirrus-CI: build as an unprivileged user >> > >> > The Cirrus-CI-provided working tree is owned by root. Leave tha= t as is >> > for simplicity but build as an unprivileged user; this tests bui= lding >> > with an unmodifiable source tree as a side effect. >> > >> > Hi Ed, >> > >> > We're still generating the LINT kernconfs into the src tree though, ri= ght? Moving that to allow for universe/tinderboxing a r/o src tree seems li= ke an obvious idea. The fact that we don't already do that implies that the= re's a non-obvious complication with that idea; does anyone know why that i= s? >> > >> > Thanks, >> > >> > Ravi (rpokala@) >> >> So, the main limiting factor here is config(8) logistics. You've got >> two questions to sort out: >> >> 1. Where in .OBJDIR do you put LINT? >> 2. How do you tell config(8) to find that LINT? >> >> I think both of these are actually pretty easy to solve. For the >> former, sys/conf/makeLINT.mk would need to be directed to put them in >> ${OBJTOP}/${.CURDIR} instead of ${.CURDIR} so that it ends up in >> ${OBJTOP}/sys/${MACHINE}/conf -- this is kind of unusual since nothing >> else will get stored there, but ultimately not a big deal. There's an >> inline patch that gets us probably the most of the way, but universe >> would still need a little bit of love. I don't think that part would >> suck much either, and it probably would clean things up a little bit >> too- for MAKE_LINT_KERNELS you wouldn't need to bother searching the >> in-tree confdir. >> >> Thanks, >> >> Kyle Evans >> >> (as an aside, I re-read Ed's commit message after this and realized I >> had asked something almost verbatim as the commit message explained >> it... sorry) >> >> [... patch omitted ...] > > Won't this break non LINT builds? Maybe we should fix the crazy way we ge= nerate lint? > We've discussed this out-of-band a little bit, but to bring it back to the list: there really isn't a reason to keep generating these LINT files, config(8) supports include these days, so we think we can just make individual LINTs include the global and per-arch NOTES and do whatever nodevice/nooptions it needs to do. To address the first question; this particular patch just taught buildkernel to look in two different places for any KERNCONF and recorded where it found the KERNCONF so that LINT/non-LINT both worked in any combination (GENERIC LINT, LINT, or just GENERIC). It's subpar compared to discontinue generation of these files, especially when you look at comments in makeLINT like: # cat is available, not sure if cp is? This is one less place to care about what's available in the build environment, especially when it's ultimately something trivial like `cat NOTES OTHERNOTES` and a series of echo. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaEfWeDr3peXYSd8LrQEunxVQuVOrEdCUizfsO-j5%2BaotA>