struct class question

struct class question

[Luben Tuikov]

Hi guys,

AFAIU, struct class describes a class of devices
for which a driver/kernel interface exists.  That is, the
implication is "struct class => driver interface (i.e. LLDD)".

The reason for this, as I understand it, is that the kernel
wants to be able to control such devices through the class
interface (and the class device interface), and possibly
hotplugging.

Thus we get the pretty flat sysfs class hierarchy:
/sys/class/<if>/<device>

But there may be devices which are embedded in the controlled
device and/or which are part of it but are _not_ directly controlled
by the kernel or the driver interface and for which no driver
interface exists.  And representing such devices on their own
doesn't make sense: they do not exist on their own or/and they
cannot be directly controlled.

Example of such devices are phys, ports, of a SAS host adapter
and expanders on the SAS domain.  They are "embedded devices",
not directly controllable by the kernel or through the kernel
interface.

Such devices are controlled by the SAS Discover process.

Now the SAS Discover process sees those devices as they're
physically (and logically) connected (simplified):

host adapter --> phys
             --> ports (may not exists)
                 --> participating phys (list, mask, etc)
                 --> SAS device (target or initiator)
                 --> expander device (edge or fanout)

I was wondering if it is viable to represent
this hierarchy, *as the SAS discover process sees it*, in
sysfs, possibly through the class interface.

So in effect, (remote) targets and initiators _would_ be present
in /sys/class/scsi_device/ (as is normal) and hosts
in /sys/class/scsi_host/ (again as is normal), but that the
picture as seen by the SAS Discover process (intermediate)
would be represented:

/sys/class/sas/
/sys/class/sas/ha0/
/sys/class/sas/ha1/
/sys/class/sas/ha1/phys/
/sys/class/sas/ha1/ports/
etc.

And this is also what the Discover process would use in order
to discover domains, control zones, configure expanders, etc.

That is, this is nothing more but my trying to export in
viewable form what the SAS Discover process saw and what it
would use.

Is this okay with kernel and scsi people?

Thanks,
	Luben

Re: struct class question

[James Bottomley]

On Wed, 2005-06-29 at 17:28 -0400, Luben Tuikov wrote:
> AFAIU, struct class describes a class of devices
> for which a driver/kernel interface exists.  That is, the
> implication is "struct class => driver interface (i.e. LLDD)".

Not necessarily "driver" interface, but device interface (which is often
implemented by a driver.  The distinction is subtle, but it's the basis
of how transport classes work).

> The reason for this, as I understand it, is that the kernel
> wants to be able to control such devices through the class
> interface (and the class device interface), and possibly
> hotplugging.
> 
> Thus we get the pretty flat sysfs class hierarchy:
> /sys/class/<if>/<device>

That's by design.  The class contains a list of all the devices
implementing the interface.

> But there may be devices which are embedded in the controlled
> device and/or which are part of it but are _not_ directly controlled
> by the kernel or the driver interface and for which no driver
> interface exists.  And representing such devices on their own
> doesn't make sense: they do not exist on their own or/and they
> cannot be directly controlled.

Interface (class) is tied to struct device.  If it doesn't have a struct
device, then it can't have a class and isn't a proper sysfs leaf.  If
the device doesn't exist or it can't be directly controlled, then we
probably don't need a class for it, right?  As to whether it needs to
exist at all if we can't do anything with it, I suppose that depends on
whether it's necessary to the tree representation or not (a bit like
channels in SCSI.  They have meaning, but no sysfs representation on
their own).

> Example of such devices are phys, ports, of a SAS host adapter
> and expanders on the SAS domain.  They are "embedded devices",
> not directly controllable by the kernel or through the kernel
> interface.
> 
> Such devices are controlled by the SAS Discover process.
> 
> Now the SAS Discover process sees those devices as they're
> physically (and logically) connected (simplified):
> 
> host adapter --> phys
>              --> ports (may not exists)
>                  --> participating phys (list, mask, etc)
>                  --> SAS device (target or initiator)
>                  --> expander device (edge or fanout)
> 
> I was wondering if it is viable to represent
> this hierarchy, *as the SAS discover process sees it*, in
> sysfs, possibly through the class interface.

Pretty much yes, that's what SCSI FC adapters do with rports.

> So in effect, (remote) targets and initiators _would_ be present
> in /sys/class/scsi_device/ (as is normal) and hosts
> in /sys/class/scsi_host/ (again as is normal), but that the
> picture as seen by the SAS Discover process (intermediate)
> would be represented:
> 
> /sys/class/sas/
> /sys/class/sas/ha0/
> /sys/class/sas/ha1/
> /sys/class/sas/ha1/phys/
> /sys/class/sas/ha1/ports/
> etc.

No, this is where you go wrong.  The sysfs tree exists under the host<n>
for scsi (and is parented to the PCI/etc device), so you can have
something like

.../host1/
.../host1/phys/
.../host1/ports/

(and obviously you need to know where you're putting the targets under
this).

So the rich deep tree is under devices and the class tree represents a
flat look into that for devices implementing the specific interface.

James

Re: struct class question

[Luben Tuikov]

On 06/29/05 18:01, James Bottomley wrote:
>>Thus we get the pretty flat sysfs class hierarchy:
>>/sys/class/<if>/<device>
> 
> That's by design.  The class contains a list of all the devices
> implementing the interface.

Ok, makes sense.

> Interface (class) is tied to struct device.  If it doesn't have a struct
> device, then it can't have a class and isn't a proper sysfs leaf.  If

Makes sense.

> the device doesn't exist or it can't be directly controlled, then we
> probably don't need a class for it, right?  As to whether it needs to

Yes, we don't need a struct device and/or struct class_device for it.

> exist at all if we can't do anything with it, I suppose that depends on
> whether it's necessary to the tree representation or not (a bit like
> channels in SCSI.  They have meaning, but no sysfs representation on
> their own).

Very good analogy.  In this respect I think we should represent
phys, ports, and expanders just as the discover process sees them,
in the same way, as you pointed out, channels are represented
even though the do not quite exist (but are an abstraction).

>>/sys/class/sas/
>>/sys/class/sas/ha0/
>>/sys/class/sas/ha1/
>>/sys/class/sas/ha1/phys/
>>/sys/class/sas/ha1/ports/
>>etc.
> 
> 
> No, this is where you go wrong.  The sysfs tree exists under the host<n>
> for scsi (and is parented to the PCI/etc device), so you can have
> something like
> 
> .../host1/
> .../host1/phys/
> .../host1/ports/

Is this

/sys/class/scsi_host/host1

Or is it (e.g.),

/sys/devices/pci0000:00/0000:00:1f.2/host1

?

> (and obviously you need to know where you're putting the targets under
> this).

True.

> So the rich deep tree is under devices and the class tree represents a
> flat look into that for devices implementing the specific interface.

In which case the flat class/ wouldn't represent phys, ports and expanders
as they do not have struct device/struct class_device; and not directly
controlled by the kernel;  just as "channel".

	Luben

Re: struct class question

[James Bottomley]

On Wed, 2005-06-29 at 19:03 -0400, Luben Tuikov wrote:
> > exist at all if we can't do anything with it, I suppose that depends on
> > whether it's necessary to the tree representation or not (a bit like
> > channels in SCSI.  They have meaning, but no sysfs representation on
> > their own).
> 
> Very good analogy.  In this respect I think we should represent
> phys, ports, and expanders just as the discover process sees them,
> in the same way, as you pointed out, channels are represented
> even though the do not quite exist (but are an abstraction).

Right, the question really is can we do anything with it, so targets
have properties (as do devices) but currently we have no channel
properties.

All SCSI devices have "ports" as defined by SAM; however, we don't show
them (well, except FC rports) because we don't use them for anything.

As far at least as SAS expanders go, I believe they do have properties
(the routing table etc.) which the driver can query, so they might be
worth adding a device for.

> Is this
> 
> /sys/class/scsi_host/host1
> 
> Or is it (e.g.),
> 
> /sys/devices/pci0000:00/0000:00:1f.2/host1

The latter (that's the devices tree under /sys/devices).

James