struct class question

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

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

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

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

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

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

Ok, makes sense.

Makes sense.

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

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

Is this

/sys/class/scsi_host/host1

Or is it (e.g.),

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

?

True.

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

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.

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

James