The floppy driver could stand a good fresh rewrite. It is too big and
twisted right now. Heck, OpenBSD's floppy driver is 1/2 the size of
Linux's in terms of lines of code and 1/8 in terms of size(1) of the
.o. If people really want to do something about kernel bloat, this
might be fruitful as it will help on just about every machine the
Linux is running on, even the Sparc and MIPS ports! The last MIPS
compile I did it was over 56k in size! Don't you think that might be
a little on the large size? The OpenBSD/Pica (mips) fd.o is only 7k
in size using the same compiler rev for both!!! The FreeBSD/intel
binary size is 10k, so I think that at least 40k if not 50k could be
saved if a good, sleek floppy driver fully integrated into the buffer
cache was produced. I don't have a recent intel kernel build handy,
or I'd be more specific.
All of this noise about a mere 16k when there are other, larger poles
in the tent is downright silly. Make sure that you get the right
things removed from the kernel first then come back later if the 16k
pole is still too big. Close analysis of the kernel will likely
reveal other areas where the code is too big and a win could happen by
simplification.
Warner
P.S. I'm not picky on the floppy driver, per se, in this message.
Just the concept of looking at some random part of the kernel and
saying that it is too big when there are other, larger parts of the
kernel that are even bigger and could easily be slimmed down. The
floppy driver in FreeBSD/OpenBSD needs to be rewritten as well and I'm
not sure if the same level of functionality is present in both or
not. A factor of 8 is kinda hard to ignore :-)
P.P.S. Please don't take this as a Linux flame. All OSes that I play
with have this problem in one area or another. It seems that very few
people these days are taking good, hard looks at code size on a
regular and recurring basis. Look at Solaris or VMS or FreeBSD or
Windows or whatever and you'll see similar things happening.