From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755790Ab1DHRVg (ORCPT ); Fri, 8 Apr 2011 13:21:36 -0400 Received: from einhorn.in-berlin.de ([192.109.42.8]:58271 "EHLO einhorn.in-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752082Ab1DHRVf (ORCPT ); Fri, 8 Apr 2011 13:21:35 -0400 X-Envelope-From: stefanr@s5r6.in-berlin.de Date: Fri, 8 Apr 2011 19:21:13 +0200 From: Stefan Richter To: Nao Nishijima Cc: Greg KH , linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-hotplug@vger.kernel.org, Kay Sievers , James Bottomley , Jon Masters , 2nddept-manager@sdl.hitachi.co.jp Subject: Re: [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel. Message-ID: <20110408192113.2f3d5eda@stein> In-Reply-To: <4D9F17DF.5030601@hitachi.com> References: <20110405124946.7969.66796.stgit@ltc233.sdl.hitachi.co.jp> <20110405161400.GA885@kroah.com> <4D9F17DF.5030601@hitachi.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Apr 08 Nao Nishijima wrote: > (2011/04/06 1:14), Greg KH wrote: > > On Tue, Apr 05, 2011 at 09:49:46PM +0900, Nao Nishijima wrote: > >> Todo: > >> - usb support > > > > Why? USB uses scsi, so why would it not work as-is today? What about > > libata devices? > > > > Sorry, my explanation was not sufficient. > It is required to get scsi id using a scsi inguiry command in order to > create the udev rule, especially in ATTR(disk_id) item in it. The USB > devices, however, do not respond to the command and we can not get their > scsi id. Identifiers and names of target ports and of logical units (per SAM-2 and later, Annex A) --- whether they are persistent, in which scope they are unique, how they look like, and how they can be obtained --- are transport specific. Neither the INQUIRY command (per SPC) nor any other command is generally useful to obtain e.g. logical unit identifiers. Any tool that needs to obtain identifiers or names of target ports and of logical units must talk with the transport driver through driver-specific interfaces. Years ago it was suggested on this list that scsi-mod exposes standard sysfs attributes for target and LU identifiers and names for all devices, so that tools that need identfiers or names have a single place where they can look them up. (The read() method of these attributes would have to be provided kernel-internally by transport drivers; and tools that read these attributes need to be aware that there is not a single format for identifiers and names.) The SCSI folks were not interested in such a more standardized sysfs ABI at that time. (There was only a proposal anyway, not a patch.) Hence, tools have to dig at various places for these SAM-2 artifacts. These ABIs have been defined ad hoc by the transport driver implementers. Anyway. /How/ to obtain identifiers is just a side issue. Back to the proposal of letting userland tell the kernel how to name devices: > >> I create unnamed devices (not > >> a block device, but an intermediate device. [...] > >> After udev finds the unnamed > >> device, udev assigns a persistent device name to a specific device > >> according to udev rules and registers it as a block device. Hence, > >> this is just a naming, not a renaming. I disagree to this conclusion. The "unnamed" device most definitely will have a name before it can be shown to userland. This preliminary name fulfills the very same requirement that "s[drt][a-z]+[0-9]*" fulfill today: It is unique within the system during the lifetime of the device. So, this /is/ renaming, only that the first name is only exposed to special tools that know of this new ABI. It seems to me that today's procedure of /not/ renaming devices but of providing as many alternative additional names as anyone could ever need (symlinks within /dev/) is more robust. If the contents of /var/log/messages or the output of iostat etc. is not what is needed, how about simply filtering that through a grep/ sed based script that rewrites names? (This needs to be run during the lifetime of the device of course, otherwise a wrong name could be put in.) The fine symlinks that udev provides can be used in such a text filter. -- Stefan Richter -=====-==-== -=-- -=--- http://arcgraph.de/sr/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Richter Date: Fri, 08 Apr 2011 17:21:13 +0000 Subject: Re: [PATCH 1/2] SCSI: Add a SCSI option for persistent device names Message-Id: <20110408192113.2f3d5eda@stein> List-Id: References: <20110405124946.7969.66796.stgit@ltc233.sdl.hitachi.co.jp> <20110405161400.GA885@kroah.com> <4D9F17DF.5030601@hitachi.com> In-Reply-To: <4D9F17DF.5030601@hitachi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Nao Nishijima Cc: Greg KH , linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-hotplug@vger.kernel.org, Kay Sievers , James Bottomley , Jon Masters , 2nddept-manager@sdl.hitachi.co.jp On Apr 08 Nao Nishijima wrote: > (2011/04/06 1:14), Greg KH wrote: > > On Tue, Apr 05, 2011 at 09:49:46PM +0900, Nao Nishijima wrote: > >> Todo: > >> - usb support > > > > Why? USB uses scsi, so why would it not work as-is today? What about > > libata devices? > > > > Sorry, my explanation was not sufficient. > It is required to get scsi id using a scsi inguiry command in order to > create the udev rule, especially in ATTR(disk_id) item in it. The USB > devices, however, do not respond to the command and we can not get their > scsi id. Identifiers and names of target ports and of logical units (per SAM-2 and later, Annex A) --- whether they are persistent, in which scope they are unique, how they look like, and how they can be obtained --- are transport specific. Neither the INQUIRY command (per SPC) nor any other command is generally useful to obtain e.g. logical unit identifiers. Any tool that needs to obtain identifiers or names of target ports and of logical units must talk with the transport driver through driver-specific interfaces. Years ago it was suggested on this list that scsi-mod exposes standard sysfs attributes for target and LU identifiers and names for all devices, so that tools that need identfiers or names have a single place where they can look them up. (The read() method of these attributes would have to be provided kernel-internally by transport drivers; and tools that read these attributes need to be aware that there is not a single format for identifiers and names.) The SCSI folks were not interested in such a more standardized sysfs ABI at that time. (There was only a proposal anyway, not a patch.) Hence, tools have to dig at various places for these SAM-2 artifacts. These ABIs have been defined ad hoc by the transport driver implementers. Anyway. /How/ to obtain identifiers is just a side issue. Back to the proposal of letting userland tell the kernel how to name devices: > >> I create unnamed devices (not > >> a block device, but an intermediate device. [...] > >> After udev finds the unnamed > >> device, udev assigns a persistent device name to a specific device > >> according to udev rules and registers it as a block device. Hence, > >> this is just a naming, not a renaming. I disagree to this conclusion. The "unnamed" device most definitely will have a name before it can be shown to userland. This preliminary name fulfills the very same requirement that "s[drt][a-z]+[0-9]*" fulfill today: It is unique within the system during the lifetime of the device. So, this /is/ renaming, only that the first name is only exposed to special tools that know of this new ABI. It seems to me that today's procedure of /not/ renaming devices but of providing as many alternative additional names as anyone could ever need (symlinks within /dev/) is more robust. If the contents of /var/log/messages or the output of iostat etc. is not what is needed, how about simply filtering that through a grep/ sed based script that rewrites names? (This needs to be run during the lifetime of the device of course, otherwise a wrong name could be put in.) The fine symlinks that udev provides can be used in such a text filter. -- Stefan Richter -===-=-= -=-- -=--- http://arcgraph.de/sr/