From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luben Tuikov Subject: Re: [RFC] SAS domain layout for Linux sysfs Date: Wed, 27 Apr 2005 11:52:11 -0400 Message-ID: <426FB52B.7080907@adaptec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from magic.adaptec.com ([216.52.22.17]:43493 "EHLO magic.adaptec.com") by vger.kernel.org with ESMTP id S261629AbVD0PwQ (ORCPT ); Wed, 27 Apr 2005 11:52:16 -0400 In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Martin Peschke3 Cc: dougg@torque.net, andrew.patterson@hp.com, Eric.Moore@lsil.com, Christoph Hellwig , Linux Kernel Mailing List , SCSI Mailing List , Madhuresh_Nagshain@adaptec.com, mike.miller@hp.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