No but making them all work the same is a great goal - and one thats
pretty close to working anyway.
> : o Drivers being able to throw away their init. code once complete.
> Yes, to save several 100s of whole bytes with average 10 drivers; could
> almost be 2-5 kbytes per system. Could be really important one or two
> days before someone wants to get 0x86 running without any main memory.
For quite a few drivers it could save one or two K. Some hardware is damned
difficult to set up. Also there is a fair bit of kernel init code in general
that could be binned after boot (all the hardware scanning for example).
That has other good effects as we can then make the machine boot scan really
smart and look for chipset specific stuff, 32bit divide bug, fpu memory
overrun, SMP B stepping bugs, chipset coherency tests etc...
> : o Uploading various patches to ftp.lmh.ox.ac.uk for a centralized deposit.
> You mean directly at everybody's door? Everything?
Its a sort of temporary (well for now ;)) archive of bits that want
considering for 2.1. Its a good a system as any other I've seen proposed.
> : o Breaking sbpcd.c apart cleanly, per family.
> Crazy. This can make me really unwilling, boy.
> sbpcd does not only support totally different drive families - it also is
> supporting them alltogether on one cable. Currently, you can mix Matsushita
> I did not assemble it to let it tear apart by playing kids, really.
So let him try. Its certainly not infeasible to try. You could consider an
sbpcd module that loaded underlying modules for different cd rom drives
(eg by kerneld) according to what is on the cable.
There is only one way to be sure someone is wrong - let them try it.
Alan