Re: Platform device id

[Jean Delvare]

On 9/11/2007, "Henrique de Moraes Holschuh" <hmh@xxxxxxxxxx> wrote:
>On Tue, 11 Sep 2007, Jean Delvare wrote:
>> I don't know your code and I don't really have the time to look at it
>> in depth, but I'm a bit surprised. Presumably your driver is
>> implementing a number of interfaces (e.g. hwmon) and you create a class
>> device for each one. You can have as many class devices hanging of a
>> (physical) device, so I fail to see why you would need to register
>> several (physical) devices.
>
>Namespace clashes.  Now that class attributes are gone (or going, whatever),
>everything lives in one namespace: the device.  I dread the day I find out
>one class I need has attribute name clashes with another, or (more likely)
>one of my driver-specific attributes clash with one from a generic class.

This shouldn't be the case. Ex-class devices still have their own
directory in sysfs. For example, the radeonfb driver spawns 4 i2c buses
(i2c-adapter class), each gets its own directory.

One problem at the moment is the hwmon subsystem, because we create the
attributes in the physical device rather than in the hwmon class device.
This is for historical reasons, but I presume that we'll have to change
this someday to work around the name space collision issue you
mentioned. If other subsystems are doing the same mistake, this can
explain your problem, but this is a subsystem implementation issue, not
a problem with class devices themselves.

>Even if clashes never happen, it can make quite a mess when you have four or
>more classes in the same device.

I don't agree. This is how things were designed.

>And you can have semanthic clashes, if one
>looks at various attributes (from different classes or driver-specific) and
>think they are related in some obvious way (only, it is not obvious at all,
>and the user didn't read the docs to know it).

There's really no reason why you would be randomly poking at attributes
without knowing which class device they belong to.

--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/