Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

["David S. Miller" <davem@redhat.com>]

   From: Jeff Garzik <garzik@havoc.gtf.org>
   Date: Thu, 31 Jan 2002 22:46:35 -0500
   
   Maybe not in this hypothetical future situation, but currently makefile
   magic was added for crc32 specifically to ensure that it is linked
   in when needed... even when CONFIG_CRC32=n.
   
   The Config.in for crc32 only exists for the case where no driver in the
   built kernel uses it... but a 3rd party module might want it.
   
My point is this: Having to say something like "CONFIG_INEED_CRC32"
for each driver that needs it is just plain stupid and a total eye
sore.

It would be really great if, some day, you just add your source
file(s) to drivers/net and that is the only thing you ever touch.  You
DO NOT touch Makefiles, you DO NOT touch Config.in files, you DO NOT
add Config.help entries.

The Makefile rules are auto-generated from keys in the *.c file(s), as
are the Config.in and help entries.  Ie. cp driver.[ch]
linux/drivers/net and then simply rebuild the tree.

Think of what kind of pains this would save from a maintainership
point of view.  When multiple new drivers are added at once we run
into all kinds of conflict issues today, whereas my scheme would do
away with that for all cases except totally new subsystems. (but I
think that could be automated in a similar fashion as well)

I have this feeling Keith Owens is going to scream "the new build
system DOES EXACTLY THAT!"  If so, that's fscking great. :-)

That is the kind of direction I'd like to see things going in.  The
lib config thing checking "if LANCE or 8130TOO or ... then force CRC32
on", on the other hand, is just garbage.  It is rediculious to expect
J. Random driver author to know to put junk into weird places like
that just to get at the crc32 routines.