public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Luben Tuikov <luben_tuikov@adaptec.com>
To: Martin Peschke3 <MPESCHKE@de.ibm.com>
Cc: dougg@torque.net, andrew.patterson@hp.com, Eric.Moore@lsil.com,
	Christoph Hellwig <hch@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>,
	Madhuresh_Nagshain@adaptec.com, mike.miller@hp.com
Subject: Re: [RFC] SAS domain layout for Linux sysfs
Date: Wed, 27 Apr 2005 11:52:11 -0400	[thread overview]
Message-ID: <426FB52B.7080907@adaptec.com> (raw)
In-Reply-To: <OF4CE413A0.DAB8B74B-ONC1256FF0.00505593-C1256FF0.0052A229@de.ibm.com>

On 04/27/05 10:54, Martin Peschke3 wrote:
> Douglas Gilbert wrote
> 
>>It has been stated that the SAS discovery algorithm (i.e. the
>>recursive use of SMP) should be implemented once in the SAS
>>transport layer so that all SAS LLDs can use it. Putting
>>the SAS discovery algorithm in the user space may be
>>even more politically correct.
> 
> 
> Similarly, in the case of Fibre Channel, a common N_Port or
> SCSI target device discovery, preferably in user space, seems
> to be desirable. This would require some CT and / or ELS
> passthrough interface, for example in order to issue queries
> to fabric switches.

This is exactly what this RFC is all about.  Having
such a representation of "what is out there", for SAS,
in sysfs, you can "address" such devices via their
sysfs file, send SMP frames to their ports, etc.

BTW, it is possible for a boot device to be on
the SAS domain.  I think it may be most convenient for
discovery (at least a basic one) to be contained in the kernel.
Implications are security, reliability, immediate access, etc.

	Luben


  reply	other threads:[~2005-04-27 15:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-27 14:54 [RFC] SAS domain layout for Linux sysfs Martin Peschke3
2005-04-27 15:52 ` Luben Tuikov [this message]
2005-04-27 18:57 ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2005-06-02 14:32 Miller, Mike (OS Dev)
2005-06-02 14:57 ` Luben Tuikov
2005-06-01 21:49 Moore, Eric Dean
2005-04-13 15:22 Luben Tuikov
2005-04-24 11:19 ` Christoph Hellwig
2005-04-25 16:06   ` Luben Tuikov
2005-04-25 16:14     ` Christoph Hellwig
2005-04-25 17:21       ` Luben Tuikov
2005-04-25 18:18         ` Christoph Hellwig
2005-04-26 15:18           ` Luben Tuikov
2005-04-27 12:34             ` Douglas Gilbert
2005-04-27 15:38               ` Luben Tuikov
2005-04-29 10:08               ` Christoph Hellwig
2005-05-02 14:35                 ` Luben Tuikov
2005-04-29 10:05             ` Christoph Hellwig
2005-05-02 14:30               ` Luben Tuikov

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=426FB52B.7080907@adaptec.com \
    --to=luben_tuikov@adaptec.com \
    --cc=Eric.Moore@lsil.com \
    --cc=MPESCHKE@de.ibm.com \
    --cc=Madhuresh_Nagshain@adaptec.com \
    --cc=andrew.patterson@hp.com \
    --cc=dougg@torque.net \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mike.miller@hp.com \
    /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