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

[Keith Owens <kaos@ocs.com.au>]

On Thu, 31 Jan 2002 20:25:09 -0800 (PST), 
"David S. Miller" <davem@redhat.com> wrote:
>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.
>...
>I have this feeling Keith Owens is going to scream "the new build
>system DOES EXACTLY THAT!"  If so, that's fscking great. :-)

Close but not quite.  I would love to do exactly that and remove all
the monolithic files like Configure.*, Config.in and Makefile.  But I
can't.

The only thing stopping me writing a simple "install this source and
the kernel detects it" model is initialization order, module_init ->
.text.init.  The initialization order is controlled by the order of
entries in Makefiles and subdirs entries between Makefiles.  That
sucks, as the recent problems with crc32.o have shown.

Two years ago I suggested breaking the implicit nexus between Makefile
order and initialization order, by adding new directives to explicitly
define initialization order - where required.  For example, group
memory must initialize before group network, within group network
driver ne2000 must initialize before driver eepro100.

As long as Makefiles control initialization order, you need monolithic
Makefiles.  Adding another layer to say which order the make entries
for each source are to be combined just compounds the problem.  Let me
separate the initialization order from Makefiles and I will happily
give you "add a source and kbuild autobuilds it" model.

Why can't I do it?  Linus wants the current method, where monolithic
Makefiles control initialization order.
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg10645.html