Re: [patch] convert the scsi layer to use struct device

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sat, 2008-03-15 at 19:56 +0100, Kay Sievers wrote:
> On Sat, 2008-03-15 at 13:31 -0500, James Bottomley wrote:
> > On Sat, 2008-03-15 at 19:04 +0100, Kay Sievers wrote:
> > > On Sat, 2008-03-15 at 11:16 -0500, James Bottomley wrote:
> > > > > We just need to create something like a "contains" link from the
> > > > > component to the scsi device, and a "enclosure" link at the scsi device
> > > > > back to the component, right?
> > > > 
> > > > Assuming you're moving to the single tree model, then I can easily do
> > > > this:
> > > > 
> > > > <real enclosure device>/<enclosure>/<enclosure component>/device -> link
> > > > to component device
> > > 
> > > Yes, sounds good. Only that there will be no meaningful "device" link
> > > with !SYSFS_DEPRECATED, we need a custom link, maintained by the
> > > enclosure itself, to do that.
> > > 
> > > > with a back link in the component device pointing to the enclosure
> > > > component.
> > > 
> > > That sounds fine.
> > > 
> > > > The way components work, probably blowing away enclosure_component_class
> > > > makes the most sense anyway.
> > > 
> > > If we go for a single class, can't we express enclosures and components
> > > in the device name and put them in the same class like:
> > > /sys/class/enclosure/
> > > |- enclosure1 -> ../../../devices/<...>/enclosure1
> > > |- enclosure1.slot1 -> ../../../../devices/<...>/enclosure1/enclosure1.slot1
> > > |- enclosure1.slot2 -> ../../../../devices/<...>/enclosure1/enclosure1.slot2
> > > |- enclosure2 -> ../../../devices/<...>/enclosure2
> > > |- enclosure2.slot1 -> -> ../../../../devices/<...>/enclosure1/enclosure2.slot1
> > > ...
> > >  
> > > while /sys/devices/<...>/enclosure1/enclosure1.slot1/ has a something
> > > like a "contains" link pointing to the SCSI device, and the SCSI device
> > > an "enclosure" link back?
> > 
> > OK, I've got a two expander system with six slots each pretending to be
> > a twelve slot installation.  I've also got two slots populated (slot 1
> > and 6).  This is what it looks like with the deprecated setting:
> > 
> > sparkweed:/sys/class/enclosure# tree
> > .
> > |-- 0:0:1:0
> > |   |-- SLOT 006
> > |   |   |-- active
> > |   |   |-- device -> ../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0/expander-0:0/port-0:0:0/end_device-0:0:0/target0:0:0/0:0:0:0
> > |   |   |-- fault
> > |   |   |-- locate
> > |   |   |-- power
> > |   |   |   `-- wakeup
> > |   |   |-- status
> > |   |   |-- type
> > |   |   `-- uevent
> 
> The components are not assigned to any subsystem. Userspace will not see
> any event for these devices, which might not be nice. Is that expected
> behavior?

Hmm, I suppose they might.  Failure of an enclosure bay is most likely a
failure of the device in that bay, but it could be for some other
reason, I suppose.

> If you assign them to the enclosure class, the device name would need
> the enclosure name prefixed, because they are not unique across
> different enclosures, right?

They can't be assigned to the enclosure class otherwise they'd get the
enclosure class interface, which is wrong for components.

> ...
> 
> > |   |-- SLOT 011
> > |   |   |-- active
> > |   |   |-- fault
> > |   |   |-- locate
> > |   |   |-- power
> > |   |   |   `-- wakeup
> > |   |   |-- status
> > |   |   |-- type
> > |   |   `-- uevent
> > |   |-- components
> > |   |-- device -> ../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0/expander-0:0/port-0:0:12/end_device-0:0:12/target0:0:1/0:0:1:0
> 
> Oh, interesting, can the parent for a whole enclosure be a SCSI LUN? Is
> that because the expander _is_ a LUN itself?

In this case, it is; but it's actually worse than that: the enclosure
spec allows the enclosure device to be embedded in a LUN (i.e. a LUN
responds as a SCSI disk but also responds to enclosure commands).
That's why the ses driver has to bind like SG.

> ...
> 
> > So are we now all happy?
> 
> If we don't need uevents for components, and no directory in /sys/class/
> which lists all enclosure components for easy finding them. And if we
> never want to send things link "change" events to userspace from an
> enclosure component, that should be ok. And we can be happy, yes. :)

It would be nice, but then we run into the enumeration problem again.
The names are taken from the actual enclosure information and are only
guaranteed unique per enclosure.  I could make up unique names, but then
they wouldn't correspond with the actual names printed on the enclosure.

> I still slightly prefer cross link-names between the component and the
> LUN like "contains" -> and "enclosure" ->, but the current one should
> work too.

OK.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html