Subject: Re: More config changes, for ro source tree and disjoint build trees
To: Brett Lymn <email@example.com.AU>
From: Travis Hassloch x231 <travis@EvTech.com>
Date: 08/19/1996 18:38:45
In message <199608131509.AAA18636@mallee.awadi> you write:
> I have come up with the
> idea that you should be able to take the dmesg output from a boot of a
> generic kernel and use the information in there to tie down all the
> hardware interrupts and so on. With a bit of appropriate user
> interaction ... offering any networky type options WITH explanations of
> what they do) you should be able to build a customised kernel for the
> machine and, possibly, build and install the kernel for the person.
I think this is a good idea. I might help.
Very nice to have explanations. Also "safe" defaults.
> I would like to use this as a chance to do some real lex/yacc work - I
> have dabbled with them before but this could be a "valid learning
> experience" :-)
There is a perl-byacc which generates a PERL "compiler", which would
be an awesome way to prototype it (or heck, even leave it in PERL for
portability over performance). Much easier than all those yacc stack
token unions. Not to mention, easy pattern matching/string manipulation.
Certainly the right tool for "text in" -> "text out". :)
> Is there a list out of the kernel with explanations? (apart from the
> vague intimations in the GENERIC kernel config comments....)
I have kept a folder of ones I came across.
Linux has a strategy of embedding descriptions (somehow) into the
kernel source itself (or maybe peripheral files which come with the source
tarball, I don't know for sure), perhaps like WEB, or more likely similar
to Java's /** */.
They have a X-based GUI (written in TCL/Tk, eeewwww) to handle the user
interaction. It's quite nice.
Obviously, requiring documentation of every #ifdef would be cumbersome
and probably detrimental to development, and I am a firm believer in
"the more options the merrier", but some kind of prioritization and
description database would be nice.