On Jan 31, Andrew.Gordon@net-tel.co.uk wrote:
> Note that CardBus is essentially PCI squeezed into a PCMCIA card shape,
> so this stuff will also affect pccardd in due course.
> As people have been posting in the past few days about re-writing pccardd
> and its config file format, perhaps this aspect needs considering
> sooner rather than later?
My amount of spare time is (still) rather limited, but
I actually do agree, that all bus types that can be
probed by directly asking a device for its ID (as is
true for at least EISA, PCI and USB, but AFAIK also
for PCMCIA in all its incarnations) should be dealt
with by the same generic probe/attach loop.
Bus types that support hot-pluggable devices will need
special support, but that should not hurt for the other
My current concept for a revised PCI bus driver has a
loop over all possible device "positions" (with some
short-cuts to reduce the name space :) and builds a
linear list of devices found.
After this list has been built, it can be handed over
to the user_config code, and after leaving that, the
attach will just try to initialize the driver that has
already been identified to apply to the device in the
At any later time (either because of an external event,
or periodically polled) the bus can be re-scanned for
new or removed devices. (This is not required for the
PCI bus, which does not even try to support insertion
or removeal of cards in operation).
After new devices have been found with no driver attached,
some user-land program should be notified, which will then
obtain a list of devices with no driver, and will try to
load an LKM for each one that might need it.
An automatic driver shutdown on device removal is much
harder to implement than the driver loading, but it is
not too har dto support from the point of view of a
generic bus driver. The hard part is left for the device
driver's shutdown() procedure ...