RE: Putting PCI-class/vendor/deviceinfo into source of PCI-driver

Bret Indrelee (bindrelee@sbs-cp.com)
Mon, 29 Nov 1999 09:20:28 -0600

Magnus Damm [mailto:damm@kieraypc01.p.y.ki.era.ericsson.se] wrote:
> > > To add new hardware ID:s to the driver and recompile would
> > > sure work for you. And for me. I would do the same thing.
> >
> > The module has to be updated anyway, if the detection code has to
> > detect new Ids.
>
> The way it is handled today, yes.
> I am very impressed to hear that someone had the guts to solve it
> as it is today... You run into problems, right?
>
> How do you solve multiple ethernet cards?
>
> I want it the other way! No initialization in the driver at
> insertion-time!
>
> No ID check in the driver at all. Maybe some kind of sanity check,
> but the goal is to keep the driver without any knowledge
> about any ID:s.
>
> Instead - A huge database with ID pairs, module name and
> extra parameters.

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.

Regardless of what you do, drivers are going to need to know the device ID.

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.

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. The driver just concatenates it's
declaration on the end of the existing file.

or

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

-Bret

-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity

Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------

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