Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Feb 1997 21:51:25 +0100
From: (Stefan Esser)
Subject:   Re: PCI LKM: How to find object file from PCI ID ...
Message-ID:  <>
In-Reply-To: <"271-970131231413-CE37*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS>; from on Jan 31, 1997 23:14:22 +0000
References:  <> <"271-970131231413-CE37*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Jan 31, 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
buses ...

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
probe() loop.

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 ...

Regards, STefan

Want to link to this message? Use this URL: <>