Block a physical property?

[Pierre Ossman]

David Zeuthen wrote:

>
> Hi,
>
> Sorry for the lag,
>

No sweat, I tend to take some time to answer things myself. :)

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

Ok. I just saw the discussions on LKML and the sentiment there was that
it would be nice to have it under /sys/class but the migration there was
unclear. It doesn't really matter. My point was that its considered a
class, not a bus device as far as the kernel is concerned.

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

That's kind of my point. I think it should have been an aspect of an
object (like storage or input) not the major defining physical bus (like
ide or pci).

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

My mistake then. Add those to storage aswell then. :)

>> Besides, if we have a block namespace, why don't we have a char
>> namespace?
>>
>
> What would be the point?
>

My point was that it seems unnecessary to have a block namespace, as it
would be to have a char namespace. When would it be interesting to know
that a node has a block device and isn't part of any other class?
Storage nodes should have a storage.dev, toasters should have a
toaster.dev and so on. A program using HAL would need to know what kind
of device it is before accessing the device node anyway, so I don't see
a gain by abstracting block device nodes.

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

My fuss was about the spec saying that info.bus is mandatory, which
evidently isn't the case since many nodes lack this property. A bug or
unclear spec?

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


Consistency. Better now before the HAL spec. gets more stable.

(I'm not trying to be an arse, I'm just trying to discuss to issues so
that we are sure the right decisions have been made :))

Rgds
Pierre