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/