From: James Bottomley <James.Bottomley@steeleye.com>
To: Douglas Gilbert <dougg@torque.net>
Cc: sullivan <sullivan@austin.ibm.com>,
Patrick Mochel <mochel@osdl.org>,
Martin Dalecki <dalecki@evision-ventures.com>,
Linux SCSI list <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] driverfs scsi for 2.5.24
Date: Wed, 03 Jul 2002 10:34:11 -0400 [thread overview]
Message-ID: <200207031434.g63EYCv01985@localhost.localdomain> (raw)
In-Reply-To: Message from Douglas Gilbert <dougg@torque.net> of "Wed, 03 Jul 2002 00:29:38 EDT." <3D227DB2.FD3D151@torque.net>
Actually, the patch already went into Linus' BK tree and will be in 2.5.25.
dougg@torque.net said:
> It will probably take a few iterations before we get close to an
> "approved" naming model :-)
That's part of the reason for putting it in early...
> I'll start with one suggestion: perhaps "kdev" could be replaced by
> two files: "major" and "minor".
I think kdev belongs in the (not yet implemented) class driver, doesn't it?
(Pat?), so we shouldn't be doing anything to expose it in SCSI. If it's done
at the class level, the kdev policy will be set globally.
I think the partition `name' file should reflect the partition UUID if one
exists, and that the disc `name' file should be mutable by root so we can do
fixups (from hotplug) for the exceptional devices that don't have a proper
unique name.
As far as numeric enumerations go, I think we can begin to move away from
them. Everything that has a parent bus no longer needs a host number since it
has a unique position in the device tree. The mid-layer itself thinks of host
enumerations in terms of a linked list, so it doesn't need the number either.
This way, we should be able to finesse all our complex host addition/removal
numbering issues that plague 2.4.
I also think that target numbers only make sense when they exist in reality
(like on a parallel bus). quite a few fibre channel drivers do internal
remapping to real target identifiers; I see no reason why they can't just
expose the ASCII representation of what they use for the device on the bus to
driverfs now.
LUNs are probably still usefully numeric, but it would be nice to use the
filesystem hierarchy to represent the SCSI-3 LUN hierarchy.
The key to using driverfs efficiently is to remember that it simply exposes to
the user how the SCSI subsystem sees the device tree. Therefore, once we have
the simplest useful device tree inside SCSI, that will be the way the user
sees it as well.
James
next prev parent reply other threads:[~2002-07-03 14:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020620112543.GD26376@gum01m.etpnet.phys.tue.nl>
2002-06-20 15:34 ` [PATCH] /proc/scsi/map Linus Torvalds
2002-06-20 16:30 ` Martin Dalecki
2002-06-20 16:58 ` James Bottomley
2002-06-20 18:27 ` Linus Torvalds
2002-06-20 20:55 ` Martin Dalecki
2002-06-20 21:04 ` Linus Torvalds
2002-06-20 21:36 ` Martin Dalecki
2002-06-20 20:12 ` Patrick Mochel
2002-06-20 22:29 ` Martin Dalecki
2002-06-22 18:42 ` Pavel Machek
[not found] ` <20020621092943.D1243@austin.ibm.com>
2002-06-21 16:17 ` Patrick Mochel
2002-07-03 4:29 ` [PATCH] driverfs scsi for 2.5.24 Douglas Gilbert
2002-07-03 14:34 ` James Bottomley [this message]
2002-07-05 1:45 ` Douglas Gilbert
2002-07-05 18:50 ` Patrick Mochel
2002-07-05 18:31 ` Patrick Mochel
2002-06-21 21:33 ` [PATCH] /proc/scsi/map Oliver Xymoron
2002-06-22 4:38 ` Nick Bellinger
2002-06-22 19:41 ` Douglas Gilbert
2002-06-22 19:11 ` Nick Bellinger
2002-06-25 18:13 ` Patrick Mochel
2002-06-25 16:05 ` Patrick Mochel
2002-06-25 16:57 ` Oliver Xymoron
2002-06-25 18:58 ` Patrick Mochel
2002-07-03 1:01 ` Pavel Machek
2002-06-20 18:32 ` Kurt Garloff
2002-06-20 18:53 ` Linus Torvalds
2002-06-21 9:07 ` Kurt Garloff
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=200207031434.g63EYCv01985@localhost.localdomain \
--to=james.bottomley@steeleye.com \
--cc=dalecki@evision-ventures.com \
--cc=dougg@torque.net \
--cc=linux-scsi@vger.kernel.org \
--cc=mochel@osdl.org \
--cc=sullivan@austin.ibm.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