scsi "target1:0:0"

scsi "target1:0:0"

[Kay Sievers]

Hi,
the recent change to the scsi-sysfs interface broke the operation of
HAL:
  http://hal.freedesktop.org
  http://vrfy.org/projects/hal/HAL-fs-uuid-udi.png
  http://vrfy.org/projects/hal/hal-spec.html

We got an additional directory in the /devices directory which
changed:
  /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host1/1:0:0:0

to:
  /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host1/target1:0:0/1:0:0:0

The inserted "target1:0:0" is _not_ backed by any "bus" or "class" device
and therefore breaks the logic of HAL to bring the devices together by
its parent. (We also don't get hotplug events for the "target*" device at
creation time)

Is this intentional and we can not expected a straight chain of devices
anymore like it always was? Shouldn't there be a "class" device to have
it consistent again.

It's the usb-storage driver with an usb-stick.

Thanks,
Kay


[kay@pim ~]$ ls -l /sys/bus/scsi/devices/
total 0
lrwxrwxrwx  1 root root 0 Nov 16 05:40 1:0:0:0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host1/target1:0:0/1:0:0:0




[kay@pim ~]$ ls -l /sys/class/scsi*
/sys/class/scsi_device:
total 0
drwxr-xr-x  2 root root 0 Nov 16 05:27 1:0:0:0

/sys/class/scsi_generic:
total 0
drwxr-xr-x  2 root root 0 Nov 16 05:27 sg0

/sys/class/scsi_host:
total 0
drwxr-xr-x  2 root root 0 Nov 16 05:27 host1




[kay@pim ~]$ ls -l /sys/block/sda/
total 0
-r--r--r--  1 root root 4096 Nov 16 05:40 dev
lrwxrwxrwx  1 root root    0 Nov 16 05:40 device -> ../../devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host1/target1:0:0/1:0:0:0
drwxr-xr-x  3 root root    0 Nov 16 05:40 queue
-r--r--r--  1 root root 4096 Nov 16 05:40 range
-r--r--r--  1 root root 4096 Nov 16 05:40 removable
drwxr-xr-x  2 root root    0 Nov 16 05:40 sda1
-r--r--r--  1 root root 4096 Nov 16 05:40 size
-r--r--r--  1 root root 4096 Nov 16 05:40 stat

Re: scsi "target1:0:0"

[James Bottomley]

On Tue, 2004-11-16 at 10:21, Kay Sievers wrote:
> We got an additional directory in the /devices directory which
> changed:
>   /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host1/1:0:0:0
> 
> to:
>   /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host1/target1:0:0/1:0:0:0
> 
> The inserted "target1:0:0" is _not_ backed by any "bus" or "class" device
> and therefore breaks the logic of HAL to bring the devices together by
> its parent. (We also don't get hotplug events for the "target*" device at
> creation time)

Could you explain what specific problem this causes.  You do get a
hotplug for the LUNs; a target is simply an additional node in the tree.

> Is this intentional and we can not expected a straight chain of devices
> anymore like it always was? Shouldn't there be a "class" device to have
> it consistent again.

Essentially yes.  a target is simply a LUN container.  It has no real
existence (it's created when the first lun is encountered and destroyed
when the last LUN is removed).  It's job is really to hold parameters
that apply to all LUNs.

James

Re: scsi "target1:0:0"

[Kay Sievers]

On Tue, 2004-11-16 at 10:33 -0600, James Bottomley wrote:
> On Tue, 2004-11-16 at 10:21, Kay Sievers wrote:
> > We got an additional directory in the /devices directory which
> > changed:
> >   /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host1/1:0:0:0
> > 
> > to:
> >   /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host1/target1:0:0/1:0:0:0
> > 
> > The inserted "target1:0:0" is _not_ backed by any "bus" or "class" device
> > and therefore breaks the logic of HAL to bring the devices together by
> > its parent. (We also don't get hotplug events for the "target*" device at
> > creation time)
> 
> Could you explain what specific problem this causes.  You do get a
> hotplug for the LUNs; a target is simply an additional node in the tree.

We sit there with the hald daemon and listen to sysfs add/remove events.
We need an event for every /sys/devices/ devices to get a unbroken chain
of devices we can sort together until we reach a root device. This is
how _all_ devices in sysfs are working and scsi was before the change.

> > Is this intentional and we can not expected a straight chain of devices
> > anymore like it always was? Shouldn't there be a "class" device to have
> > it consistent again.
> 
> Essentially yes. a target is simply a LUN container.  It has no real
> existence (it's created when the first lun is encountered and destroyed
> when the last LUN is removed).  It's job is really to hold parameters
> that apply to all LUNs.

Yes, that is fine. But if you don't want to add "class" support for
"target*" they should have at least a "bus" associated to emit hotplug
events on creation time. Here is what udevinfo prints. There should be
no device in the middle of a chain without a "bus" I think:

device '/sys/block/sda/sda1':
    SYSFS{dev}="8:1"

device chain '/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host2/target2:0:0/2:0:0:0':
    BUS="scsi"
    ID="2:0:0:0"

device chain '/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host2/target2:0:0':
    BUS=""
    ID="target2:0:0"

device chain '/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host2':
    BUS=""
    ID="host2"

device chain '/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0':
    BUS="usb"
    ID="3-1:1.0"

device chain '/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1':
    BUS="usb"
    ID="3-1"

device chain '/sys/devices/pci0000:00/0000:00:1d.1/usb3':
    BUS="usb"
    ID="usb3"

device chain '/sys/devices/pci0000:00/0000:00:1d.1':
    BUS="pci"
    ID="0000:00:1d.1"

device chain '/sys/devices/pci0000:00':
    BUS=""
    ID="pci0000:00"
    SYSFS{detach_state}="0"

Thanks,
Kay

Re: scsi "target1:0:0"

[Matthew Wilcox]

On Tue, Nov 16, 2004 at 05:55:53PM +0100, Kay Sievers wrote:
> We sit there with the hald daemon and listen to sysfs add/remove events.
> We need an event for every /sys/devices/ devices to get a unbroken chain
> of devices we can sort together until we reach a root device. This is
> how _all_ devices in sysfs are working and scsi was before the change.

On *your* machine, maybe.  On a parisc machine, you get a PCI root device
with no bus type in the middle of a tree, like this:

/sys/devices/parisc/10/10:4/pci0000:02/0000:02:01.0/0000:03:07.0

here, parisc and pci0000:02 have no bus type.  10 and 10:4 are of type
"parisc" and 0000:02:01.0 and 0000:03:07.0 are "pci".

> device chain '/sys/devices/pci0000:00/0000:00:1d.1':
>     BUS="pci"
>     ID="0000:00:1d.1"
> 
> device chain '/sys/devices/pci0000:00':
>     BUS=""
>     ID="pci0000:00"
>     SYSFS{detach_state}="0"

There you go, it's just another example of this one.  It's just faulty
assumptions in hald by the looks of things.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: scsi "target1:0:0"

[David Zeuthen]

On Tue, 2004-11-16 at 17:10 +0000, Matthew Wilcox wrote:
> There you go, it's just another example of this one.  It's just faulty
> assumptions in hald by the looks of things.
> 

Please explain how you expect userspace to keep track of the device tree
and enforce policy if we don't get hotplug events for things in the
middle of the tree?

Thanks,
David

Re: scsi "target1:0:0"

[James Bottomley]

On Tue, 2004-11-16 at 11:23, David Zeuthen wrote:
> Please explain how you expect userspace to keep track of the device tree
> and enforce policy if we don't get hotplug events for things in the
> middle of the tree?

The full path to the device is part of the environment of the event. 
Can't you simply parse this?

I'm already getting complaints in the other direction (too many SCSI
hotplug events) from the large system people.  I'm really loth to
introduce more simply as a convenience for a user space daemon.

Really, I think there should only be hot plug events from real entities
(which, more often than not are only the leaf nodes of the sysfs trees).

James

Re: scsi "target1:0:0"

[David Zeuthen]

On Tue, 2004-11-16 at 11:25 -0600, James Bottomley wrote:
> On Tue, 2004-11-16 at 11:23, David Zeuthen wrote:
> > Please explain how you expect userspace to keep track of the device tree
> > and enforce policy if we don't get hotplug events for things in the
> > middle of the tree?
> 
> The full path to the device is part of the environment of the event. 
> Can't you simply parse this?
> 

I suppose that userspace can just ascent up the tree and ignore devices
inbetween instead of assuming that every device in the middle has a bus
or class? That would probably work, yeah.

> I'm already getting complaints in the other direction (too many SCSI
> hotplug events) from the large system people.  I'm really loth to
> introduce more simply as a convenience for a user space daemon.
> 
> Really, I think there should only be hot plug events from real entities
> (which, more often than not are only the leaf nodes of the sysfs trees).
> 

That makes sense to me. Which leads me to ask: are there any
documentation spelling out what userspace should expect and what sorts
of guarantees there is in general for sysfs ABI? That would be useful to
prevent situations like this.

Thanks,
David

Re: scsi "target1:0:0"

[greg k-h]

On Tue, 16 Nov 2004 12:23:03 -0500, David Zeuthen wrote:

> On Tue, 2004-11-16 at 17:10 +0000, Matthew Wilcox wrote:
>> There you go, it's just another example of this one.  It's just faulty
>> assumptions in hald by the looks of things.
>> 
> 
> Please explain how you expect userspace to keep track of the device tree
> and enforce policy if we don't get hotplug events for things in the
> middle of the tree?

You do get hotplug events for those devices in the device tree, just no 
bus is assigned to them, right?

That should still work out just fine, as Matthew has pointed out, other
devices in the device tree do not have busses either.

thanks,

greg k-h