lkml.org 
[lkml]   [2005]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: struct class question
From
Date
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


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

\
 
 \ /
  Last update: 2005-06-30 00:04    [W:0.051 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site