According to Travis Hassloch x231:
>
>I think this is a good idea.  I might help.
>Very nice to have explanations.  Also "safe" defaults.
>

Yep.

>
>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". :)
>

I must admit doing the thing in perl would be a doddle.  I have done
quite a bit of perl code which helps.  The reason I have been avoiding
going down that path is the fact that I wanted something that would be
available in a minimal install situation.  Mainly because I feel that
the people that would get the most use out of the kernel builder
(considering the name abc for it....) are the people that have not
come to grips with the system and, hence, are unlikely to have
installed anything but the base system.

Also, Perry Metzger had a an idea that sounds very sensible.  Bypass
dmesg altogether and just snarf the information out of the kernel
itself.  This would be more reliable than handling the dmesg output
and it has the side effect of being able to implement a
"prtconf/devinfo" style command that would tell you what is on the
system hardware-wise since the kernel-walk code would be the same for
both abc and devinfo, just the backend would be different.

>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 /** */.

Yes, this would be nice.  I was considering:

find /usr/src/sys \( -name '*.c' -o -name '*.h' \) -print | xargs egrep '#ifdef.*[A-Z0-9_-].[A-Z0-9_-]*' | sort | uniq

To try and find all the defined ones.

>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.
>

It would be very nice to know the ones that directly affect getting
things running (e.g. ppp, SBPRO....) and leave the debug ones until
last on the basis that if you want the debug info then you probably
RTFS anyway....

-- 
Brett Lymn, Computer Systems Administrator, AWA Defence Industries
===============================================================================
  "Upgrading your memory gives you MORE RAM!" - ad in MacWAREHOUSE catalogue.