no ndis* at cardbus?

[David Young]

Then there's the right way: roll CardBus into PCI. :-)

While I'd love to see this happen (and I suspect it's sorely overdue),

Please don't do this, at least not unless you know
exactly wat you are doing.
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.

From my perspective, deleting a zillion redundant device attachments
and redundant type/value definitions from dev/cardbus/, and saving
developers the time they spend writing redundant attachments, is
a substantial gain. Integration of CardBus and PCI could be the
foundation for proper PCIe / ExpressCard support, rather than
something in the way of it.

Dave

[David Young]

Post by David Young

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.

Post by David Young
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.

Post by David Young
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

[Matthias Drochner]

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

Sorry if I created the impression that I question
your (or anybody else's) ability to find a reasonable
design.
But it would add complexity in any case, and likely
increase code size for the simple case where no
hotswap or so support is needed at all.

FreeBSD integrated PCI and CardBus. That does not mean
that it is a good idea, or that it has been a success for FreeBSD

Our autoconf structure (the driver/attachment split)
is completely different and I think we can do better
than FreeBSD as far as modularity is concerned.
When we'll get driver demand loading to work well, we'll
be happy that things are well seperated.

best regards
Matthias




-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich

Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On May 29, 2:33am, Christos Zoulas wrote:
} In article <***@vtn1.victoria.tc.ca>,
} John Nemeth <***@victoria.tc.ca> wrote:
} >
} > It's on my project list to do something about this. Right now,
} >16-bit PC Card (commonly known as "PCMCIA") is broken. And, as you
} >note, CardBus is fragile.
}
} Right now all 16 bit pcmcia cards that I have are broken. I think this
} should be fixed before 5.0 is released.

Hmm... I wasn't really planning on doing anything with this until
after 5.0. It could easily take me a couple months or more to digest
PC Card, NetBSD's implementation, and to figure out what is up and fix
it. It's starting to sound like there are enough issues that 5.0 could
potentially be pushed back into the beta stage. I suspect that releng
wants 5.0 out the door in less then two months, so this isn't good.

I should also dig out my old laptop hard drive. Since my network
connections (wired and wireless) are via 16-bit PC Card and CardBus,
this would mean that upgrading would put my laptop completely out of
commission which I can't have. Unfortunately I moved recently and have
no idea where the hard drive is. Given the small size of a laptop hard
drive, it could be almost anywhere.

}-- End of excerpt from Christos Zoulas

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Jul 5, 5:50pm, Matthias Drochner wrote:
} ***@victoria.tc.ca said:
} > Given how closely related CardBus and ExpressCard are to PCI, PCMCIA
} > should probably be rolled into PCISIG.
}
} Maybe, but for $2000 or 3000 a year to get access to specs
} this is also a business model.

You don't have to be a member to get specs (at least some of
them). PC Card Standard is available for $499, and ExpressCard
Standard is available $2500. See http://www.pcmcia.org/bookstore.htm .
I will grant you that those prices aren't cheap. PCI specs are also
available at suitably high prices, see
http://www.pcisig.com/specifications/order_form . I found PICMG specs
at https://www.picmg.org/v2internal/specorderformsec-nonmember.htm .

} > I hope this CompactPCI
} > stuff only adds to the PCI standard and doesn't modify it.
}
} It is completely independent, at least as far as software
} is concerned. PCI hotplug (rev. 1.1) doesn't contain any
} register level specification - all is up to proprietary
} controller chips. CompactPCI hotplug requires that the

Yuck.

} peripheral cards comply, there is a "capability" defined
} (PCI_CAP_CPCI_HOTSWAP in our pcireg.h) which contains the
} bits needed at the card side. The host side is proprietary
} too afaict.

Yuck. Okay, these two items means that a driver would be needed
for every different host chip that we wanted to support. I can see
wanting to put those into modules.

} > drivers have to deal with the device going away
}
} Afaict only CardBus can deal with this, because it is a point-
} to-point link with an own interrupt controller. The others
} need notification in advance. With shared interrupts this
} would be impractical otherwise.

The problem is that with hotswap the device can go away without
notice even if it isn't supposed to do so. It would be nice to do
something sensible in that case.

}-- End of excerpt from Matthias Drochner

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de