RE: Flaw in the driver-model implementation of attributes

From: Perez-Gonzalez, Inaky (
Date: Wed Jun 18 2003 - 02:48:59 EST

> From:
> 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)

  attr2 ... sysfs specific attrs
  block/ ... block layer specific attrs
    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):

  attr2 ... sysfs specific attrs
  block/ ... block layer specific attrs
    part0/ ... partition specific stuff
      attr2 ...
  ide/ ... ide layer specific attrs

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)
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

This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:23 EST