Date: Wed, 18 Jul 2001 05:00:07 -0700 From: Peter Wemm <peter@wemm.org> To: Dima Dorfman <dima@unixfreak.org> Cc: audit@freebsd.org Subject: Re: queue(3) patch for config(8) Message-ID: <20010718120007.0BAF4380B@overcee.netplex.com.au> In-Reply-To: <20010718111129.720EF3E2F@bazooka.unixfreak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dima Dorfman wrote:
> Peter Wemm <peter@wemm.org> writes:
> > Dima Dorfman wrote:
> > > Sheldon Hearn <sheldonh@starjuice.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010718120007.0BAF4380B>