Messages in this thread | | | Date | Mon, 29 Nov 1999 17:02:34 +0100 | From | Magnus Damm <> | Subject | Re: Putting PCI-class/vendor/deviceinfo into source of PCI-drivers |
| |
> Vendors usually change the device ID for a reason. > > Any device driver that accepts multiple devices IDs probably needs to know > which device ID a particular instance of the device it is working with. If > the programming interface hadn't changed, there would have been no reason to > change the device ID.
The same vendor will stick to the same ID:s until the hardware change, yes. But when different vendors do "compatibe" hardware things change.
IDE / Uart / Soundblaster
I think the pcmcia-cs kit has solved things very good.
If I have a look at /etc/pcmcia/config (debian) I can see that there are plenty different cards from different vendors that use the same driver. If they do the same checking in the driver source file I don't know, though.
> Regardless of what you do, drivers are going to need to know the device ID.
Most of them, anyhow. We say all. =)
> A more workable method would be to completely change the whole device driver > interface, starting at register_chardevice()/register_blkdevice(). Design it > so everything is hot swappable, and that the same detection mechanism is > used everywhere.
Right on target!
I mean - PCI, PCMCIA and even ISA-PNP has got ID codes.
> Couple of ways to do the detection: > > 1. The device driver has an external configuration file that creates the > link between vendor/device id/sub-vendor/sub-device-id and the driver to > handle that. A varient of insmod searchs this file to determine which driver > to load when it detects a new device.
I am with you.
> The driver just concatenates it's declaration on the end of the existing file.
Sorry, I don't understand what declaration / file you mean.
> 2. The driver registers a dev-op that includes a routine to probe the device > (hey driver! do you handle this guy), and another routine to attach a > particular instance of the device. This is done instead of the current > register_chrdevice()/register_blkdevice(). > > Each has its own problems. The first has a centralized database that can > become corrupted. Provided this is just a text file, you can probably fix > it. It is still a pain.
It is a pain if you have to keep up muliple copies of the same information. A centralized database, yes. If you corrupt your database you are screwed. But what the heck, if you corrupt your partition table things look worse.
> The second method has the problem that you have to > have at least the routine to register the device and recognize it's device > IDs loaded. If this is happening at kernel level, that is not a happy thing. > If it is happening at application level, you now have two different > executables for a single device driver. Yuch!
You mean some kind of race condition..?
Regards,
Magnus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |