linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jw schultz <jw@pegasys.ws>
To: linux-kernel@vger.kernel.org
Subject: Re: Does sysfs really provides persistent hardware path to devices?
Date: Sun, 17 Aug 2003 19:04:25 -0700	[thread overview]
Message-ID: <20030818020425.GB10453@pegasys.ws> (raw)
In-Reply-To: <20030817182847.GA2422@kroah.com>

On Sun, Aug 17, 2003 at 11:28:47AM -0700, Greg KH wrote:
> On Sun, Aug 17, 2003 at 08:41:31PM +0400, Andrey Borzenkov wrote:
> > On Monday 28 July 2003 21:03, Greg KH wrote:
> > [...]
> > > > Question: how to configure udev so that "database" always refers to LUN 0
> > > > on target 0 on bus 0 on HBA in PCI slot 1.
> > >
> > > If you can't rely on scsi position, then you need to look for something
> > > that uniquely describes the device.  Like a filesystem label, or a uuid
> > > on the device.  udev can handle this (well I'm still working on the
> > > filesystem label, but others have already done the hard work for that to
> > > be intregrated easily.)
> > >
> > 
> > I tried to explain that I can rely on SCSI position but kernel does not give 
> > me this SCSI position. Apparently we have some communication problem. You do 
> > not understand my question and I do not understand what you do not understand 
> > :) I attribute it to my bad English.
> > 
> > Let's avoid this communication problem. You show me namedev.config line that 
> > implements the above. If it really does it - it is likely I understand what 
> > you mean better and won't bother you with stupid questions anymore. If it 
> > does not do it - I can immediately point out where it fails.
> 
> Here's the line that I used in my demo at OLS 2003 for udev:
> 
> 	# USB camera from Fuji to be named "camera"
> 	LABEL, BUS="usb", vendor="FUJIFILM", NAME="camera"
> 
> This is a scsi device on the USB bus that has the vendor name "FUJIFILM"
> in it's scsi sysfs directory.
> 
> Now, partition issues asside (all partitions of this device will be
> named camera, camera1, camera2, etc., but I'm working on identifying
> partitions better) this shows that the vendor of a scsi device is able
> to be named uniquely.

<OT>
That's nice.  Now add a second camera from the same vendor
:(  No, i don't expect you to be able to uniquely identify
identical devices being added and removed from a single USB buss
in a persistent way.  But it would be nice if we could get
consistency between busses so that a mouse on one USB buss
weren't confused with a mouse on another USB buss.
</OT>

> Does that help?  Have you looked at the 2003 OLS paper about udev for
> more information?

Actually you have not answered his question.  And i think it
a reasonable one.  It could be it was answered elsewhere.

>>>> Question: how to configure udev so that "database" always refers to LUN 0
>>>> on target 0 on bus 0 on HBA in PCI slot 1.
>> Let's avoid this communication problem. You show me namedev.config line that 
>> implements the above.

I'll try to put slightly differently.  I'll concede that we
cannot positionaly identify USB devices so lets set that
aside for the nonce.  We can persistently, positionaly
identify a device within the HBA context (BUS +ID + LUN) and
should be able to do the same for a PCI HBA (PCI slot +
device) or (PCI bridge topology).

So can i uniquely identify using persistent positional
information a drive at PCI_slot=1, HBA_on_card=0, BUS=0,
ID=1, LUN=0?  And how do i uniquely identify it in the udev
config file so that adding the same model drive in the same
BUS+ID+LUN on an same model HBA card in another PCI slot
does not confuse the two?  If i cannot, can i at least do
the identification so that adding ID=0,LUN=0 to the scsi buss
doesn't cause a name change.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

  reply	other threads:[~2003-08-18  2:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-26 16:36 Does sysfs really provides persistent hardware path to devices? Andrey Borzenkov
2003-07-26 16:43 ` Randy.Dunlap
2003-07-26 16:50 ` Greg KH
2003-07-28 16:44   ` Andrey Borzenkov
2003-07-28 17:03     ` Greg KH
2003-08-17 16:41       ` Andrey Borzenkov
2003-08-17 18:28         ` Greg KH
2003-08-18  2:04           ` jw schultz [this message]
2003-08-18 20:47             ` Greg KH
2003-07-26 16:54 ` OSDL
2003-07-26 16:59 ` J.C. Wren
2003-07-26 17:07   ` Greg KH
2003-07-26 22:51   ` Dax Kelson
2003-08-18  6:21 "Andrey Borzenkov" 
2003-08-18 20:42 ` your mail Greg KH
2003-08-31 10:54   ` Does sysfs really provides persistent hardware path to devices? Andrey Borzenkov
2003-09-24 21:18     ` Greg KH
2004-01-17 20:34       ` Andrey Borzenkov
2004-01-17 21:34         ` Greg KH
2004-01-19 13:08         ` Olaf Hering
2004-01-19 13:59           ` Andries Brouwer
2004-01-19 14:04             ` Olaf Hering
2004-03-14 11:53           ` Andrey Borzenkov
2004-03-14 19:25             ` Horst von Brand
2003-08-19 17:56 David Brownell

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=20030818020425.GB10453@pegasys.ws \
    --to=jw@pegasys.ws \
    --cc=linux-kernel@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;
as well as URLs for NNTP newsgroup(s).