From owner-svn-src-head@freebsd.org Wed Sep 23 15:04:54 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 357213FC8CD; Wed, 23 Sep 2020 15:04:54 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BxM0k0Fzdz3TGr; Wed, 23 Sep 2020 15:04:54 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id DC2BF26DDB; Wed, 23 Sep 2020 15:04:53 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f175.google.com with SMTP id q5so23122269qkc.2; Wed, 23 Sep 2020 08:04:53 -0700 (PDT) X-Gm-Message-State: AOAM531JyPoVbsw9ZRoXyC3pLxqW0YYA8X/UiXKeXG5YlnetWHpizN84 /IRh3xCP2FMxyiQYwPpFDioqBfuJdo6Cn921caE= X-Google-Smtp-Source: ABdhPJw0wzGWOft9FrFtbM4eskbb+/AYgsgUdSxtOmfVfmD8LsCPZTQWZwmZfjs0h/E9Srn+w6SaDWfIpoTs7KqhyKI= X-Received: by 2002:a37:43ca:: with SMTP id q193mr249523qka.493.1600873493545; Wed, 23 Sep 2020 08:04:53 -0700 (PDT) MIME-Version: 1.0 References: <202009171847.08HIlNXa015641@repo.freebsd.org> In-Reply-To: From: Kyle Evans Date: Wed, 23 Sep 2020 10:04:41 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r365846 - head To: Warner Losh Cc: Ravi Pokala , Ed Maste , src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 15:04:54 -0000 On Wed, Sep 23, 2020 at 9:30 AM Warner Losh wrote: > On Wed, Sep 23, 2020, 7:21 AM Kyle Evans wrote: >> >> On Mon, Sep 21, 2020 at 7:23 PM Ravi Pokala wrote: >> > >> > -----Original Message----- >> > From: on behalf of Ed Maste >> > Date: 2020-09-17, Thursday at 11:47 >> > To: , , >> > 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