Re: no ndis* at cardbus?

[David Young <dyoung%pobox.com@localhost>]

On Tue, Feb 10, 2009 at 09:33:37PM +0100, Matthias Drochner wrote:
> 
> dyoung%pobox.com@localhost said:
> > > For a minimal gain, it would make even more a mess of the
> > > PCI framework, and it would be in the way of proper
> > > PCIexpress/Expresscard support.
> > I think that you may have made some assumptions that you are not
> > telling us about. 
> 
> It doesn't need assumptions, just facts.
> There are significant differences: autoconfiguration (no device
> addressing), interrupts and power management. The latter two
> are actually areas which are somehow delicate.
> Merging this into the PCI framework would require conditionals
> and hooks which noone would understand anymore after a while.
> (OK, that's an assumption, but a well based one.)
> In any case it is the opposite of modularity.
> 
> Also, pci and cardbus are controlled by different standards
> bodies (PCISIG vs PICMG). This means that while it is already
> hard to meet someone with access to one of the specs, it is
> even more unlikely that someone hacking on the code can
> check against both.
> 
> The vendor/device IDs are kept coherent, but a chip designed
> for PCI will not work on cardbus unless specifically designed
> for this. So the cardbus namespace is much much smaller, and
> it will stay that way.
> A cardbus does only show up behind a "cbb", and we need a specific
> driver for cbbs anyway for power handling etc. This is quite
> different from the situation in PCI where we can handle unknown
> bridges because they are standardized.
> 
> >From my perspective, deleting a zillion redundant device attachments
> 
> There are nineteen atm, and while we might still grow some hardware
> support it will be a handful more if at all.
> Cardbus is dead, most new laptops don't have it.
> It's also not so rendundant because it contains the cardbus
> specific power handling. (I agree that some more code could
> be shared but I suspect that spec availability is a bit
> in the way here.)
> 
> And the cardbus code uses "rbus" which is somewhat fragile. Without
> a good reason I'd prefer to keep it away from the PCI code.
> 
> > Integration of CardBus and PCI could be the
> > foundation for proper PCIe / ExpressCard support
> 
> A "foundation" (buzzword bingo or what) would be the lowest
> common denominator for me, not something where special cases
> are merged in.

Matthias,

I see that the integration of CardBus and PCI that you have constructed
in your head is a morass of complexity designed by simpletons; you have
thoroughly demolished their design, and rightfully so.  I don't think
that anybody who foresees such an evil result as you do will set out to
integrate PCI and CardBus; if they do, I hope that they read and they
are discouraged by your warnings.

You may chalk it up to a positive outlook, or my naivete (actually,
I *was* born yesterday), but I think that I see a better way than to
integrate CardBus with PCI than to reuse rbus, to create a maze of
special cases in the PCI code, or to get hung-up on power-handling, and
I still hold that it is not only possible, but it is a good idea!

BTW, ISTR that FreeBSD integrated PCI and CardBus.  That does not mean
that it is a good idea, or that it has been a success for FreeBSD, but
maybe we both should start our research there, hmmm?

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933