Messages in this thread | | | Date | Thu, 3 Jun 1999 13:59:05 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 2.3 wish: integrate pcmcia into mainstream kernel |
| |
On Thu, 3 Jun 1999, David Hinds wrote: > > 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.
That's the only part I feel that is REQUIRED.
The above is the part that I'm not even going to argue about - it's going to happen whether people agree with me or not. If worst comes to worst, I'll end up writing the code the way I had to write the initial code for USB, just because I disagreed with what was going on in USB development. And for the same reason - I refuse to have a Linux machine around that I can't easily boot new kernels on..
My solution would probably only handle the specific Ricoh solution or whatever, the same way my initial USB code only handled UHCI and the PIIX4.
This is why I started doing Linux in the first place: I wanted to have UNIX on my computer. To me it is almost a personal affront to have a computer that Linux doesn't boot on very well. And I really only care about the computers I have access to, although being a stickler for having a design I want it to be extensible to other situations too.
> 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.
Umm..
The only reason normal drivers don't know about insertion and removal is because they haven't had to deal with it before. We'll make them deal with it. It would be easy to add a per-interrupt-descriptor "disable" bit, for example, so that when a specific card was removed only THAT particular interrupt never happens any more (so PCMCIA devices could use the normal "request_irq()" and "free_irq()" logic, and yet we'd make it work right so that when a card is removed only THAT particular interrupt goes away - instead of getting interrupts from another card that got inserted).
This is the second and more insidious problem with the current PCMCIA "outside the mainline kernel" - none of the PCMCIA issues ever get fixed. Because nothing else would be using them - the infrastructure just never gets built up, and then you complain about the fact that you can't find out what interrupts are in use.
OF COURSE you can't find out, because why should the kernel have such an interface when it never uses it? Why do you expect it would ever be maintained?
A lot of these issues have some counter-parts in other hot-pluggable buses (hut-plug PCI, USB etc), so while the kernel will grow it will at least grow not just because of PCMCIA, but because we have support for the common concepts. See?
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/
| |