Date: Wed, 21 Jul 2004 03:27:22 +0200 From: Max Laier <max@love2party.net> To: freebsd-hackers@freebsd.org Cc: freebsd-config@freebsd.org Subject: Re: "Next Generation" kernel configuration? Message-ID: <200407210327.29307.max@love2party.net> In-Reply-To: <20040721010342.GA8398@Odin.AC.HMC.Edu> References: <XFMail.20040720193931.conrads@cox.net> <20040721010342.GA8398@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--Boundary-02=_Bac/AGbBUnTVzB7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 21 July 2004 03:03, Brooks Davis wrote: > On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote: > > Just musing on an idea here: > > > > I've been thinking for a while now about trying to write a tool to make > > kernel configuration easier, sort of a "make config" (as in ports) for > > the kernel, similar to what's available on some of the Linux distros. > > > > Ideally, such a tool would be capable of automatically adapting itself > > to handle and present as choices, in an orderly and logical fashion, > > whatever devices, options, etc. were currently available, as defined by > > the files in /sys/conf et al. > > > > The major hurdle to overcome, it appears to me, is that the scheme > > currently employed to describe the available devices, options, etc. > > does not lend itself very easily at all to any kind of automatic > > parsing or other manipulations. Determining dependencies between > > components programmatically, for one thing, seems well near impossible. > > The NOTES files, in their current form, make even finding the comment > > associated with a particular option or device extremely difficult, if > > not impossible. > > > > Has this ever come up for discussion before? Now that we have rcNG, > > with its explicit declarations of dependencies, has any thought been > > given to doing something similar with kernel configuration files? > > Something still human-readable, yet more orderly and systematic, easier > > for a machine to interpret, present and verify? > > There have been previous discussions. They should be visiable in the > archives if you can find the magic search strings. > > > A dependable tool offering a menu-driven means of configuring the > > kernel, ensuring proper config file syntax, dependency handling, > > prevention of incompatible options, etc. -- as well as online > > documentation, advice, suggestions and warnings, plus perhaps a nice > > set of default selections -- would be a very nice addition to the > > system. But to bring it about, obviously a major reworking of the > > current system of kernel configuration files would be required. > > You can have my simple flat file kernel config when you pry it from my > cold, dead hands and I know a number of other develoeprs share this > viewpoint. All my experiences with the linux visual kernel config tool > have been annoying and I've got friends with more expierence with it > that have much less kind things to say. Add me to the list. And this realates to sys/conf/* as well (respondig to t= he=20 re-reply). Especially developers prefer *clean*, *simple* config files and = I=20 (personally) would really really hate to twiddle with some insane XML just = to=20 add something to the build! > That said, so long as it doesn't impose too much developer burden, > an improved set of backend files that did a better job of handling > dependencies and knew which options where relevent given the configured > set of devices could be useful. http://www.freebsd.org/releases/5.3R/todo.html has a "Desired features"-ite= m=20 saying: "Revised kld build infrastructure", which will pretty much interfer= e=20 with this. You might want to contact with the current owner (peter@) and he= ar=20 what he has to say. Other than that, I'd welcome a somewhat enriched config= =20 environment as long as it is done reasonable and makes the job easier! And= =20 please: NO XML! > There is a valid question of what a depenency means. For instance, you > can't really have IP networking without lo(4) (there's a null pointer > derefrence if you try), but since you can load it as a module, should > you have to compile it in? There should be levels of dependencies ... i.e. the TBD config-tool would=20 (strongly) suggest that you build-in lo(4) into an "options INET" kernel, b= ut=20 should not stop you to do else. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_Bac/AGbBUnTVzB7 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBA/caBXyyEoT62BG0RAiBVAJ4qxg1UcSPtME3K6DfaqdOEtWahlQCffcBO Ic3LNMcpcEj/HVQdrBMkqaQ= =b9p+ -----END PGP SIGNATURE----- --Boundary-02=_Bac/AGbBUnTVzB7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407210327.29307.max>