RE: Flaw in the driver-model implementation of attributes

[Perez-Gonzalez, Inaky]

> From: [e-mail]
> On Tue, Jun 17, 2003 at 08:44:50PM -0700, Perez-Gonzalez, Inaky wrote:
> 
> > Maybe this is going to kill my argument as an analogy, but think
> > about a C++ class hierarchy, where belonging to a class means
> > ...
> 
> But there is no inheritance here.  Block device and IDE disk are
> different objects and relation is not "A is B with <...>", it's
> "among other things, A happens to use B in a way <...>".

Well, the device is an IDE disk that is linked through an IDE 
controller that is linked through a PCI controller to the system bus. 

That IDE device presents an interface. The block layer just presents 
the common interface that all block devices present (and that IDE
and SCSI disks are able to provide) - there is no inheritance, but
the concept is the same.
 
> Moreover, there is no such thing as "physical device 
> of that block device". There might be many.  There 
> might be none.  IOW, we have a bunch of constructors 
> for class "block device" and some of them happen to have
> some kinds of physical devices among their arguments. 

[I happen not to know the block layer as well as you and many others 
do, so please correct me where I am wrong ...]

So what? _every_ block device will have some form of physical 
back-up that can be linked back into sysfs.

In cases like this, doesn't it make sense to have some 
/sys/devices/SOMETHING/ hierarchy for those  "logical" or "virtual" 
devices that back-up those block devices? 

You could even say that RAID and ramdisks -as used in the example 
above- would belong to /sys/devices/"virtual"/raid/ and 
...../ramdisks/; after all, you have to create those devices before
being able to attach them (last time I checked):

(using subdirs for each layer for clarity)

/sys/devices/"virtual"/raid/0
  attr1
  attr2     ...   sysfs specific attrs 
  block/    ... block layer specific attrs
    attr1
    attr2
    component1 -> /sys/devices/pci/FOO/block/part1  
    component1 -> /sys/devices/pci/BAR/block/part4  

(I would also love to see the block device node being dropped in 
the corresponding "block" directory, but that's another story).

And extrapolating even more, I'd expect to see something 
like this for the block devices that are part of a physical device 
(partitions, I mean):

/sys/blabla/pci/3.14159/ide0/0.0
  attr1
  attr2     ...   sysfs specific attrs 
  block/    ... block layer specific attrs
    attr1
    attr2  
    part0/  ... partition specific stuff
      attr1
      attr...
    part1/
      attr1
      attr2 ...
  ide/      ... ide layer specific attrs
    attr1
    attr2 

In the tree structure it makes sense, because each block
device, at the end is or a partition (and thus is embedded
in a "true" block device) or a true block device on a 1:1
relationship with a physical device.

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