Almost none of that would be needed, at least for the normal IDE CD case.
The normal built-in IDE driver can obviously driev the hardware. If the
_only_ thing we did in kernel space was some very simple cardbus logic
(PCI-only, detect the cardbus chip, query it for devices, and handle the
special cases that we care about), I bet it wouldn't be more than a few kB
worth of driver.
And _because_ it would be integrated into the standard kernel, it woul
dnow make sense to have the regular IDE driver be aware of the
pluggability issues. It already knows about some of them, but it's not
really all that integrated.
Do the same for floppy controllers, and you've covered 95% of all modern
notebook issues with 5% of the effort.
> The
> overhead for config files is minimal if we are only handling IDE: say
> 1K for the rc script, and just a couple lines for a config file for
> IDE devices. Bottom line: 70K > 35K, it won't fit.
I disagree. Bottom line: a kernel that is 5kB larger, partly because of
the cardbus detection code, partly because of slightly enhanced support
for it in the current drivers.
> PCMCIA floppy support in general is painful because of the DMA issue.
Floppies in _general_ are painful. The floppy driver is the LARGEST driver
in the whole kernel, and most of that is just code to take care of really
stupid issues with DMA and interrupts.
[ well, technically there are larger drivers, but they tend to do a lot
more, and often a noticeable portion of the size is because they have
downloadable sequencer code etc.. ]
Adding the code to make it know about some PCMCIA issues would make sense.
But only if the kernel know about PCMCIA in the first place, something it
doesn't right now.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/