[lkml]   [2001]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] New Driver Model for 2.5

> > Hmm. So, this would be a device ID, much like the Vendor/Device ID pair in
> > PCI space?
> Except for the fact that the Vendor/Device ID pair is a device *class*
> identifier, and the uuid is a device *instance* identifier.

Actually, the Vendor/Device ID pair is a unique identifier for the device
model. There are a Base Class and Subclass IDs, as well as a subsystem
vendor ID.

There are equivalents in USB. But, neither of them are globally unique
identifiers for the device. That doesn't necessarily mean that one
couldn't be ascertained from the device; ethernet cards do have MAC
addresses. But, I don't think that many will have a ID/serial number.

And this leads to inconsistency. You'll have PCI devices that have a
Vendor/Device/Class ID, and some that have a device-specific ID. Then
you'll have USB devices with the same. And what about legacy devices?

Which leads me to the question: what real benefit does this have? Why
would you ever want to do a global search in kernel space for a particular
device? The bus structure can keep (and likely already does keep) this
information. It can export it to userland on its own; the top layer
doesn't need to do that.

Yes, the formats of each file will be different, but they would be anyway.
The names may be different for different buses, but we can encourage the
bus layers to all export a file of the same name ("ID") if we want.

I don't think the UUID belongs in the top level structure. It belongs in
whatever structure dictates it - the bus structure or the class strucutre.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:08    [W:0.071 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site