Date: Wed, 10 Dec 1997 16:00:15 -0800 From: Jonathan Mini <j_mini@efn.org> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: The Classiest Man Alive <ksmm@cybercom.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <19971210160015.21473@micron.mini.net> In-Reply-To: <21861.881769454@time.cdrom.com>; from Jordan K. Hubbard on Wed, Dec 10, 1997 at 07:57:34AM -0800 References: <Pine.BSI.3.95.971210100036.27436C-100000@kalypso.cybercom.net> <21861.881769454@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm sure that if more of these suggestions started being accompanied > by actual working code, they'd meet with a much different reception. > I heard from one guy who was working on something called "kconfig", > but at last update it had bogged down at the most critical stage, that > being the part where all the kernel configuration options are > presented in menu form. The copy I reviewed did everything *but* that > rather important bit. :-) If nobody else steps up an volunteers to within the next few days, I'll do it. 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. 2) another file, or part of the file above, which contains all of the possible DEVICES, including pseudo-devices, a few "common" possible conifgurations for each device, and a short comment explaining what each does. Please do not point me at LINT, this does not provide the needed info in a machine-readable format. Also realise that this means that someone will need to keep this file (or files) maintained, so that the "pretty" kernel config system can actually be used to make kernels with new devices. (I wouldn't mind maintaining those files, by watching the incoming CVS messages and then committing the appropriate modifications to the "directory" (that would, of course, require commit priviledges)) Once this "pretty" interface was used to select a set of devices, options, etc, you would have three options : 1) spit this config out to a config(8) input file. I'm assuming I'd be able to read a config(8) file back in (shouldn't be hard, a little work with lex for a few hours) 2) do 1, and autoamtically run config(8). 3) do 2, and run make all (possibly after running make depend) 4) possibly do 3, and run make install I think you get the idea. The input file would allow me to collect data like this on a device or option : device sio desc "Serial Port Driver" bus isa? spl tty vector siointr conf port "IO_COM1" irq 4 conf port "IO_COM2" irq 3 conf port "IO_COM3" irq 5 conf port "IO_COM4" irq 9 option COMCONSOLE "Prefer serial console to video console" option COM_ESP "enable code for Hayes ESP" option COM_MULTIPORT "enable code for some cards with shared IRQS" option DSI_SOFT_MODEM "enable code for DSI Softmodem" option BREAK_TO_DEBUGGER "enable a BREAK from the comconsole to drop to DDB" manpage 4 sio endd This, which I rolled off the top of my head, (so don't bind me to the format) basically has information I gleaned from LINT about the sio device. It says that the short name for it is "Serieal Port Driver", it's available for any of the isa buses, it sits in the tty spl, uses siointr for it's vector function, had the four above common configurations, (which the user could select from as well as defining a "custom" one. This allows for idiot users to say "oh! "COM1".. I know that..") has the above options, whith the short descriptions sitting next to them, and for further information, point the user to the man page sio(4). (In realisty, it would probably be "select here to see the man page" or something) That is the type of info that FreeBSD will need to keep in a machine-readable format in order to be able to generate kernels in a pretty way. ... Note that a utility like this would be very useful as a front end to a dynamically-loadable module system, since the utility could as easily modify a set of loaded modules as anything else. -- 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?19971210160015.21473>