I'm describing the current problem, not the solutions.
> 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.
Linus, I think you should ask me a few things about CardBus and PCMCIA
before spouting off stuff like this. It's pretty clear to me, now,
that you just don't know how CardBus bridges function. A CardBus
bridge is a PCI bridge, with an ordinary 16-bit PCMCIA host controller
stuck on the side. CardBus does not simplify handling of 16-bit cards
in ANY way. ALL the old 16-bit cruft is still there. There is no
"very simple" PCI-only CardBus logic for handling 16-bit devices.
Read my whole message. You're correct to the extent that with a
fairly small driver, we could special-case detect an IDE card that was
configured by the BIOS, and pass the resource info to the kernel IDE
driver. And then hack the PCMCIA package to notice that the socket is
already configured. The hand-off would be a little tricky, but yes,
it could be done.
> 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.
I don't understand this. If you expect your 5kb kernel add-on to
handle hot insertion and removal, I have a bridge to sell you.
> Do the same for floppy controllers, and you've covered 95% of all modern
> notebook issues with 5% of the effort.
As I said, the issue with floppies is complex due to the DMA issue.
If that is solved, then sure, any solution to the IDE problem would be
trivial to extend to handle floppies.
> > 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.
I was describing how things are, not how things might be. That's why
I called it "background", not "proposed solutions".
-- Dave Hinds
-
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/