> Well, there's butt-loads of ugly Makefile shit all over the place. It
> isn't going away.
Some of it went away when Keith Owens rewrote modules-install.
More of it went away between 2.2 and 2.4. Check out drivers/net/Makefile
or drivers/scsi/Makefile or lots of other Makefiles, for instance.
They are 1/3 the size they used to be.
Even more of it's going away in 2.5.
Here's my contribution to making it go away:
ftp://ftp.shout.net/pub/users/mec/kbuild/dancing-makefiles-2.3.26
ftp://ftp.shout.net/pub/users/mec/kbuild/x-Dkm-9.diff
Where is yours?
> Yes and no. You can only insmod _one_ serial.o so the name does have
> to be unique at the time it's loaded.
True. But the Makefiles are no longer part of this problem.
> (BTW, the current modutils (2.3.15) won't see all the modules from a
> modules_install.)
Oh? That would be a bug. Which modules does it fail to see?
> From an efficiency standpoint, one file per directory is a hideous waste
> of both filesystem space (one inode and one block) and system resources
> (file access times, dcache, et. al.)
So, go benchmark "insmods per second". I want to see a %age from some
controlled test where the only differences are the module arrangement
and the version of modutils used.
Then tell us about what use case you have where this metric matters.
If you say "I have a custom embedded system where every filesystem block
matters", then I will say: "so go into the modules directory and arrange
the directory structure the way you like it".
I'll tell you what matters to me: correctness and simplicity.
Keith killed a lot of swampy nasty code and I'm grateful.
That's way more important to me than the "file access time"
difference between /lib/modules/2.4.0/char/serial.o and
/lib/modules/2.4.0/kernel/drivers/char/serial.o.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:31 EST