Block a physical property?

[David Zeuthen]

Hi,

Sorry for the lag,

Pierre Ossman wrote:
> Pierre Ossman wrote:
> 
>>How come 'block' is considered a physical property (a bus even) and not
>>a functional property? It seems a bit weird from my point of view. That
>>something is block based seems more of a protocol detail than anything else.
>>
>>I know the sysfs layout is a but funky concerning block devices, but the
>>concensus seem to be that it should be eventually moved to /sys/class/block.

No, this will never change (see archives on linux-hotplug for greg kh 
and kay (both udev maintainers) saying this) because it's a change that 
will gain us nothing and only break existing user space...

>>
>>Also, the block "bus" forgets to set info.bus. ;)
>>
> 

It's not a bus at all.. it's just properties on device objects.. but see 
  below.

> After sleeping on it, I started wondering why we have this namespace at
> all. Wouldn't it be better to move block.device into storage? And
> major/minor seems a bit linux specific. So it should probably be under
> the linux namespace.

I don't think major/minor is Linux specific. I believe it is POSIX.

> Besides, if we have a block namespace, why don't we have a char namespace?
> 

What would be the point?

> I also noticed that all functional nodes in the HAL tree were missing
> info.bus. Could cause some trouble since the spec says it's mandatory. I
> suppose they should inherit it from their parent. Which would make
> storage.bus obsolete (provided that block goes the way of the dodo).

storage.bus is just shorthand for looking at info.bus at the hal device 
object with the udi referenced in storage.physical_device.

> Just my take on the situation. :)

I'm not sure what the point would be.. Really.. the things that are 
interesting (wrt volumes and drives) are these

  1. the volume capability and volume.* properties
  2. the storage capability and storage.* properties
  3. certain block.* properties

I don't see what we gain by renaming this?

Cheers,
David