RE: Flaw in the driver-model implementation of attributes

[Perez-Gonzalez, Inaky]

> From: Kevin P. Fleming [mailto:[e-mail]]
>
> These are two wildly differing views, but yes, they are the same device.
> These differing attributes do _not_ belong in the same directory. An
> application looking at your IDE devices does not really care how the
> block subsystem perceives those devices (i.e. hdparm). Conversely, an
> application looking at your block devices should not care about what
> underlying physical devices (if any :-) they are associated with. 

But that is describing a physical mapping vs. a logical view.

I can think of many different "views" I want to see (IDE, block,
physical, block sorted by size, the ones who are green and sing 
in Basque...) but only one is unique and inherently defined: the
physical one. 

I guess I agree with Alan; I'd prefer something like:

/sys/devices/pci0/0000:00:07.1/ide0/0.0/
  attr1
  attr2 ...   sysfs specific attrs 
  block-attr1
  block-attr2 ... block layer specific attrs
  ide-attr1
  ide-attr2 ... ide layer specific attrs

(or make that TAG- a subdirectory of the device if you wish,
that is just an example). 

This way, for each device I have an *unique* location where to
track it, and an easy way to hunt down attributes specific to
each layer that controls it.

And when, when I want to make logical views (again, by IDE, by
block device ...), I can do that from user space and create a
tree full of symlinks to the unique, physical locations.

Maybe this is going to kill my argument as an analogy, but think
about a C++ class hierarchy, where belonging to a class means
to inherit that class' methods. When an object is instantiated
and its class inherits a lot of other classes, it inherits all
the methods of those classes. Your methods are the attrs, and
you can access them with the same pointer, you don't  need to
look somewhere else ...

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)