I could see that. In some cases (ISA devices in particular), they'd probably
be blank all of the time, and would be taken out of the equation.
> > * serial number
> > * content-cookie
> > * topology-cookie
> You need another field that contains a identifier for the bus or the scheme
> of the device id, because different busses use different formats and you
> cannot compare them.
Since topology-cookie would be opaque, it doesn't matter what bus its sitting
on....its either the same or its different. As long as "pci bus 0, slot 1"
turns into the same cookie each time, and is always different than the
"isa io=330" cookie then no problem.
> You could also merge content-cookie and serial number because you will always
> to interpret them together.
Not necessarily, from other posts, serial number may or may not be unique.
All of the fields would probably be interpreted at the same time, but keeping
them separate would handle 'odd' cases that we've not thought of at this point.
> > I suppose these ID fields could also be used by a userspace tool to
> > load/unload drivers as necessary.
> There is a problem with that idea: you often cannot generate the device id
> before the driver is available. Things like the content cookie and the serial
> number must be created by the driver, at least in some cases. For example a
> PCI ethernet card has a great serial number, its hardware address, but you
> can only get it after the driver has been loaded.
Hmm. True. However, most of the other fields (Vendor/model, topology) would
be available before the driver is loaded. Shouldn't that be enough to figure
which driver to use? Of course, ISA devices cause problems here...come to
think of it, ISA devices cause problems no matter what we do :)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/