Initial version of PCI access library

Ian Romanick idr at us.ibm.com
Mon Feb 20 11:42:38 PST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Hellwig wrote:
> On Mon, Feb 20, 2006 at 10:03:44AM -0800, Jesse Barnes wrote:
> 
>>Internally, the server does an iteration scheme similar to what your 
>>library provides (or at least some part of it did last time I looked, 
>>Egbert can provide more details).  But I think the important thing is 
>>the interface exposed to the drivers, and they typically just want to 
>>bind to a device based on vendor and device ID (though maybe a small 
>>survey of drivers is in order to make sure we provide the right 
>>interfaces).  That's why in the initial thread about PCI access I 
>>argued for a simpler device matching scheme, similar to the one Linux 
>>provides to its drivers.
> 
> I think the most important thing about the driver interface is that
> it should be a callback scheme where the core calls the driver for
> every found devices instead of the driver calling some kind of iterator
> code.  From experience with Linux kernel drivers the latter leads to
> rather horrible spaghetti code, not to mention that such a scheme
> doesn't work at all for dyanmic devices additions or removals.

I agree 100%, but SOMETHING still has to iterate over the list of
devices.  If the devices aren't doing it, then the X server is.

My current understanding is that right now each driver has a probe
function.  The server calls that probe function to ask the driver which
devices it can handle.  This includes PCI, AGP, ISA, SBUS, and Zorro
devices.  The driver marks devices as "claimed" and does some per-device
initialization.  Based on discussions from the past couple weeks, I
believe that this is backwards.

For PCI, AGP, and other busses with enumeratable device IDs (PCMCIA?
USB?), the driver should have a list of devices IDs and a probe
function.  If the server finds a device that is in the driver's list, it
calls the driver's probe function with a pointer to the device.  That
driver now owns that device.

We'll need another probe function for those older busses.  Fortunately,
most drivers don't support any devices on those types of busses, so code
to support that entry point won't be needed very often.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD+huuX1gOwKyEAw8RAoTLAJ9efUKEgUhZSHeXLMy+XT+K5D8rGACgmqPC
szgpoMCmKf2nBUmCgPMr3Xk=
=4ALd
-----END PGP SIGNATURE-----



More information about the xorg mailing list