From: Greg KH <greg@kroah.com>
To: linux-kernel@vger.kernel.org
Subject: Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Date: Wed, 14 Mar 2001 10:15:26 -0800 [thread overview]
Message-ID: <20010314101526.A15137@wirex.com> (raw)
In-Reply-To: <3AAF8A71.1C71D517@faceprint.com> <Pine.SGI.4.31L.02.0103141026460.532128-100000@irix2.gl.umbc.edu> <20010314082643.A1044@kochanski.internal.splhi.com>
In-Reply-To: <20010314082643.A1044@kochanski.internal.splhi.com>; from timw@splhi.com on Wed, Mar 14, 2001 at 08:27:10AM -0800
On Wed, Mar 14, 2001 at 08:27:10AM -0800, Tim Wright wrote:
> This would currently be massive overkill for Linux, but DYNIX/ptx avoids this
> problem entirely by keeping a device naming database. This became necessary
> when we added support for multi-path fibre-channel connected disks. Most
> device-naming conventions rely on "physical" addresses i.e. this disk at the end
> of this bus connected to this controller in this PCI slot is /dev/sdd. The
> Solaris scheme mentioned above is no different in that respect. Unfortunately,
> it doesn't work with multi-path FC-connected devices.
>
> Very briefly, devices that are "id-able" i.e. already have a unique id are
> simply entered into the database (SCSI drives have a unique id that you can
> read at autoconf time). For elements that are not "id-able", we establish
> a derived id by recording their relation to "id-able" elements. At boot time,
> we scan (in parallel) the system and compare what we find to the database.
> That way, you get consistent naming for devices, and, at least in the case of
> the SCSI (or FC) drives, the name doesn't change, even if you pull a drive
> from one bus and plug it into a different bus entirely.
This comes up a lot with regards to USB devices too. One of the
usb-serial drivers (the edgeport driver) did something like this by
looking at the topology of the USB bus and where a specific device was
(it was also helped by unique serial numbers) and allowed the devices to
be assigned device nodes based on the topology and a small user space
program. I'm going to try to do this for all usb-serial devices in 2.5
I can see a scheme like this being very useful for all USB, FireWire,
scsi, etc type of devices.
And no, I don't think that having some type of device naming "database"
is overkill and will eventually make it into parts of the kernel (the
"database" living outside of the kernel of course...)
greg k-h
--
greg@(kroah|wirex).com
next prev parent reply other threads:[~2001-03-14 18:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-13 16:41 Linux 2.4.2ac20 David Balazic
2001-03-13 19:24 ` Nathan Walp
2001-03-13 23:02 ` Tim Wright
2001-03-14 9:31 ` David Balazic
2001-03-14 15:12 ` Nathan Walp
2001-03-14 15:36 ` magic device renumbering was -- " John Jasen
2001-03-14 16:27 ` Tim Wright
2001-03-14 18:15 ` Greg KH [this message]
2001-03-15 1:53 ` Tim Wright
2001-03-15 2:08 ` Greg KH
2001-03-14 18:23 ` Christoph Hellwig
2001-03-14 18:45 ` Peter Svensson
2001-03-14 19:11 ` Lars Kellogg-Stedman
2001-03-14 19:34 ` Andreas Dilger
2001-03-14 19:44 ` Richard B. Johnson
2001-03-15 13:46 ` John Jasen
2001-03-14 20:01 ` Christoph Hellwig
2001-03-16 9:11 ` Stephen C. Tweedie
2001-03-14 19:16 ` Andreas Dilger
2001-03-14 20:08 ` John Jasen
2001-03-15 3:04 ` Stephen Degler
-- strict thread matches above, loose matches on Subject: below --
2001-03-15 21:50 Mikael Pettersson
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=20010314101526.A15137@wirex.com \
--to=greg@kroah.com \
--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