From owner-freebsd-audit Wed Jul 18 5: 0:13 2001 Delivered-To: freebsd-audit@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 4C50237B401 for ; Wed, 18 Jul 2001 05:00:07 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f6IC07M19515 for ; Wed, 18 Jul 2001 05:00:07 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 0BAF4380B; Wed, 18 Jul 2001 05:00:07 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Dima Dorfman Cc: audit@freebsd.org Subject: Re: queue(3) patch for config(8) In-Reply-To: <20010718111129.720EF3E2F@bazooka.unixfreak.org> Date: Wed, 18 Jul 2001 05:00:07 -0700 From: Peter Wemm Message-Id: <20010718120007.0BAF4380B@overcee.netplex.com.au> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dima Dorfman wrote: > Peter Wemm writes: > > Dima Dorfman wrote: > > > Sheldon Hearn writes: > > > > This one should almost certainly go past Peter Wemm. > > > > > > Okay. Peter (cc'd), the discussion is about a patch (attached below) > > > to config(8) which converts all of its lists to the queue(3) API. > > > This will make future modifications (esp. those which start removing > > > arbitrary nodes from these lists) less error-prone. Please review. > > > > > > Thanks, > > > > Please keep in mind that: > > 1: This code is doomed and will not live to 5.0-RELEASE. > > What's included in `this code'? You're planning to do away with > config(8) entirely? Yes. I have several incomplete prototypes for replacements. The most promising ones use a hybrid C / script arrangement that have a script call a helper to parse the user config file and spit out a bunch of simple tables. The scripts generate the rest of the build structure from there. > > 2: TAILQ_FOREACH() etc is not portable. If you're going to use this, then > > please provide fallbacks. The strl*() needs to be fixed in the same way > > as it is a major headache to build a newer kernel on an older system. > > Okay, I'll get rid of *_FOREACH. Or provide #ifndef TAILQ_FOREACH / #define TAILQ_FOREACH in the config.h file. That's relatively harmless. > > 3: We dont remove nodes from lists at all right now, at all. > > I know. Some people wanted nooption/nodevice directives that will > undo option/device to go along with 'include'. Those will need to > remove nodes. Ahh, I see. > > The > > TAILQ_REMOVE()'s you've added are artificial as we're destroying the > > entire list. There was no need to remove the notes as we're free()'ing > > it as we go. This change just seems to complicate the code. > > 4: config (in general) doesn't free memory. The few token places that > > do free memory (eg: the ones you're touching) are just a drop in the > > bucket compared to some of the other stuff. There are no reference > > counts etc, things are just strdup()'ed all over the place "in case". > > > > If you still want to do it, then go for your life. But keep in mind that > > it is right up on the top of my personal todo list for nuking this entire > > block of code. > > As asked above, which part of the code is going away? I did this in > preparation of adding nooption/nodevice directives as described above. > People on -hackers (mostly jhb) wanted to split the kernels into MD > and MI parts; the include directive I added will allow us to do that, > but people wanted 'nooption' and 'nodevice' so that (in theory) it'd > be possible to have a 'base' kernel config file for, e.g., a group > ("cluster"?) of machines, with a small per-machine config file that > would customize the base one (by adding or removing options and/or > devices). > > As long as kernel config files and kernel options aren't going away, > it seems like this would be pretty useful. As I said before, if you still want to do it, feel free and go right ahead. I have a system that has elements of what you describe above on the agenda to replace config entirely (part of the unified kernel / modules build stuff). I see no harm at all in adding missing functionality in the meantime and it will keep me on my toes. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message