Date: Wed, 10 Dec 1997 23:49:09 -0800 From: Jonathan Mini <j_mini@efn.org> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Jonathan Mini <j_mini@efn.org>, The Classiest Man Alive <ksmm@cybercom.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <19971210234909.29178@micron.mini.net> In-Reply-To: <24904.881819698@time.cdrom.com>; from Jordan K. Hubbard on Wed, Dec 10, 1997 at 09:54:58PM -0800 References: <19971210160015.21473@micron.mini.net> <24904.881819698@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard <jkh@time.cdrom.com> stands accused of saying: > > What I have in mind is rather simple, but it requires the following : > > > > 1) a file, which is MAINTAINED, which contains all of the possible > > options, their classes, and a simple comment for each one. > > Woog. It's that "maintained" bit which is the hard part, and frankly > I'm more than somewhat skeptical of this for the long-term unless it's > taken to the next level of functionality which will properly encourage > its upkeep. Yes. That is the reason I capitalized it. > What I'm thinking of here, namely, is the total replacement of config > by a new utility which tries for a different configuration file > format, one "rich" enough to support a GUI interface. This has always > been a shortcoming of the current one, and the need to keep GENERIC > and LINT files around just to "document" it is rather significant > proof of its shortcomings. If you're really this ambitious then tou > won't get anywhere by simply trying to paper over config, you need to > replace it. Ok. I was shooting for a 'minumum work' approach, and then once I got people used to the GUI I was going to be radical and start talking about replacing it with the new config junk. But, you're one step ahead of me. We need to do this in three stages then : 1) decide what types of "configurability" we want to allow the config utility to handle. compile-time options, compiled-in device, managing LKMs (for now, I hope to see the kld code replace it) and other types of kernel behavior would be a good idea too. Plausably, we could extend this to cover any sort of system configuration, but whether we want to do that is what we'd talk about in this stage. 2) Once we have what we want to classify in our database defined, we should decide on a database method to store it. Most likely, due to extendability, a relational database will be the product of this stage. The exact format would be the issue under debate here. 3) Then I get to actually write the database-handling code, and the GUI to deal with it. If you don't mind, I indent to not use libdialog. :) 4) (I know I said three stages, but..) Then we get to maintain the configuration database. This should be "easier" than maintaining LINT, since you basically won't be able to compile a device in without "documenting" it in the database. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971210234909.29178>