Aligning GENERIC with NOTES?

[Quincey Koziol]

Hi all,
    I've put my reorganized versions of GENERIC and GENERIC.hints here:
        ftp://hdf.ncsa.uiuc.edu/pub/outgoing/koziol/GENERIC
        ftp://hdf.ncsa.uiuc.edu/pub/outgoing/koziol/GENERIC.hints

    I've tried to add information from the NOTES files where appropriate, but
keep the changes to the comments on the devices/options/etc lines minimal so
that these commands generate a very small diff:  (I know that it's possible to
fix these commands to generate essentially no diffs, but I'll leave that perl
script up to someone with more time and perl-fu than I have right now... :-)

sleipnir# grep -v ^# GENERIC.new | grep -v ^$ | sort > & new
sleipnir# grep -v ^# GENERIC | grep -v ^$ | sort > & old
sleipnir# diff -w old new

    I didn't go ahead with reorganizing the NOTES files to be more consistent
with each other (i.e. list SCSI options, then ATA options, then NIC options,
etc) because I haven't had the time yet.

    I know that changing the format of GENERIC is a potential bikeshed issue,
but it would be nice if GENERIC wasn't _quite_ as crufty as it is...  (There's
a couple of places where options are listed in really odd orders... :-)

    BTW: it would be nice if mergemaster reviewed differences in GENERIC and
the NOTES files also...

    Quincey

> At 3:35 PM -0800 2004/02/17, Randy Bush wrote:
> 
> >>  It is the less experienced/less knowledgeable people for whom we
> >>  should be concerned about with regards to POLA.
> >
> >  and when current becomes stable?
> 
> 	Then we can make wholesale changes in the new current, while 
> making almost exclusively incremental improvements in stable.
> 
> >  what is the functional improvement of the change?  what will
> >  the user actually get for the pain?
> 
> 	A GENERIC kernel description that is more intelligently 
> organized?  More easily understood?  More easily modified to suit 
> situations that are close but not quite exactly the same?
> 
> >  a very very few of us who think the generic kernel text has
> >  crufted to the max over the years will.  10^(2..3) users who
> >  just make kernels will not be happy.
> 
> 	Most users probably never make another kernel, or at least don't 
> know that's what they're doing.  Of those that do, most probably 
> won't see the kernel files, they'll just rebuild what's there.
> 
> 	However, the next group of users will see the files and it would 
> be very useful to the community as a whole for these files to be 
> well-organized, and in line with NOTES.  Doing this right will help 
> reduce the number of questions asked related to this topic, and 
> eliminate the dumber questions that would have been asked if people 
> had read and understood the kernel file correctly, but got confused 
> because of the cruftage.
> 
> -- 
> Brad Knowles, <brad.knowles at skynet.be>
> 
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
>      -Benjamin Franklin, Historical Review of Pennsylvania.
> 
> GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
> !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
> tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
>