From: Patrick Mansfield <patmans@us.ibm.com>
To: "Philip R. Auld" <pauld@egenera.com>
Cc: Steven Dake <sdake@mvista.com>, linux-scsi@vger.kernel.org
Subject: Re: [announce] scsi_id 0.1 - generate unique scsi id
Date: Mon, 27 Oct 2003 09:31:16 -0800 [thread overview]
Message-ID: <20031027093116.A21595@beaverton.ibm.com> (raw)
In-Reply-To: <20031027120631.E4263@vienna.EGENERA.COM>; from pauld@egenera.com on Mon, Oct 27, 2003 at 12:06:31PM -0500
On Mon, Oct 27, 2003 at 12:06:31PM -0500, Philip R. Auld wrote:
> Rumor has it that on Mon, Oct 27, 2003 at 07:27:33AM -0800 Patrick Mansfield said:
> I haven't gotten to play with 2.6 yet, so I'm not sure exactly what udev does.
udev is a device naming or dynamic dev program, pretty much a replacement
for devfs. See:
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
> However, as long as scsi_id generated the same value for udev it shouldn't
> be an issue for that. It's just got to match what it found last time
> it booted to make sure it names the device node the same way, right?
Yes. But broken or devices not fully supporting page 0x80 or 0x83 might
give the same id for different devices.
> Which leads to a question about how this works with udev. If it gets the same
> value for multiple paths to a devive won't udev them make a single device node?
I'm not sure what it will do now, or how to integrate it (or not integrate
it) with multi-path. For dm/md multipath, as long as we have a way to
persistently name its block devices there is no issue. But, each of the
underlying devices should still be made available - that is, udev should
still create a separate dev entry for each path, even if the devices all
have the same identifying information.
> > And, It is not clear if the specific code called should be a separate
> > program or a new function. A separate program can be released independent
> > of scsi_id, but that means we will need common or duplicated code: mainly
> > for the sg_io usage, and decoding of the result, especially the sense
> > data.
> >
>
> A separate program that is called based on the config file makes sense to me.
> It could then be independent as you say. A small general purpose dynamic sg_io
> library could remove the code duplication.
That is possible, but more work, and again I don't have any such devices.
AFAIK dynamic libraries won't work for initramfs or initrd. I have not
tried scsi_id with them, I don't know what the plan is for udev. But we
can use whatever solution udev comes up with ;-)
-- Patrick Mansfield
next prev parent reply other threads:[~2003-10-27 17:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-21 23:58 [announce] scsi_id 0.1 - generate unique scsi id Patrick Mansfield
2003-10-22 14:31 ` Christoph Hellwig
2003-10-22 7:42 ` Daniel Stekloff
2003-10-22 14:46 ` Christoph Hellwig
2003-10-22 8:05 ` Daniel Stekloff
2003-10-22 15:52 ` Matthew Wilcox
2003-10-22 16:15 ` Patrick Mansfield
2003-10-22 16:23 ` Christoph Hellwig
2003-10-23 7:33 ` Jes Sorensen
2003-10-24 21:33 ` Steven Dake
2003-10-27 14:16 ` Philip R. Auld
2003-10-27 15:27 ` Patrick Mansfield
2003-10-27 17:06 ` Philip R. Auld
2003-10-27 17:31 ` Patrick Mansfield [this message]
2003-10-28 14:19 ` Philip R. Auld
2003-10-28 15:06 ` Patrick Mansfield
2003-10-28 15:40 ` Philip R. Auld
2003-10-28 16:29 ` Patrick Mansfield
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=20031027093116.A21595@beaverton.ibm.com \
--to=patmans@us.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=pauld@egenera.com \
--cc=sdake@mvista.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