svn commit: r365846 - head

[Kyle Evans]

On Wed, Sep 23, 2020 at 9:30 AM Warner Losh <imp at bsdimp.com> wrote:
> On Wed, Sep 23, 2020, 7:21 AM Kyle Evans <kevans at freebsd.org> wrote:
>>
>> On Mon, Sep 21, 2020 at 7:23 PM Ravi Pokala <rpokala at freebsd.org> wrote:
>> >
>> > -----Original Message-----
>> > From: <owner-src-committers at freebsd.org> on behalf of Ed Maste <emaste at FreeBSD.org>
>> > Date: 2020-09-17, Thursday at 11:47
>> > To: <src-committers at freebsd.org>, <svn-src-all at freebsd.org>, <svn-src-head at 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 that as is
>> >       for simplicity but build as an unprivileged user; this tests building
>> >       with an unmodifiable source tree as a side effect.
>> >
>> > Hi Ed,
>> >
>> > We're still generating the LINT kernconfs into the src tree though, right? Moving that to allow for universe/tinderboxing a r/o src tree seems like an obvious idea. The fact that we don't already do that implies that there's a non-obvious complication with that idea; does anyone know why that is?
>> >
>> > 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 generate 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