Re: struct class question

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

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