public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
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



  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