public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Luben Tuikov <luben_tuikov@adaptec.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Cc: Greg KH <greg@kroah.com>
Subject: struct class question
Date: Wed, 29 Jun 2005 17:28:08 -0400	[thread overview]
Message-ID: <42C31268.8010606@adaptec.com> (raw)

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




             reply	other threads:[~2005-06-29 21:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-29 21:28 Luben Tuikov [this message]
2005-06-29 22:01 ` struct class question James Bottomley
2005-06-29 23:03   ` Luben Tuikov
2005-06-29 23:30     ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42C31268.8010606@adaptec.com \
    --to=luben_tuikov@adaptec.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox