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/