From: Douglas Gilbert <dougg@torque.net>
To: sullivan <sullivan@austin.ibm.com>
Cc: Patrick Mochel <mochel@osdl.org>,
Martin Dalecki <dalecki@evision-ventures.com>,
Linux SCSI list <linux-scsi@vger.kernel.org>
Subject: [PATCH] driverfs scsi for 2.5.24
Date: Wed, 03 Jul 2002 00:29:38 -0400 [thread overview]
Message-ID: <3D227DB2.FD3D151@torque.net> (raw)
In-Reply-To: 20020621092943.D1243@austin.ibm.com
[-- Attachment #1: Type: text/plain, Size: 10160 bytes --]
Attached is Mike Sullivan's driverfs patch which was released
on June 21. It has been minimally changed so it applies to
lk 2.5.24 .
Here are Mike's original notes:
Mike Sullivan wrote:
>
> The driverfs patch for SCSI that was recently posted was the kernel portion of
> a device naming project that is intended to support all devices, at least the
> ones that implement to driverfs in a standard way. There are three items that
> IMHO should be considered as part of the standard set that driverfs requires:
>
> 1. device type - It appears that Pat is heading down this path with the class
> type support so maybe this is a no brainer. Currently the scsi
> driverfs provides a "type" file to contain this info. The current
> strings used are taken from the scsi_device_types[] but should be
> replaced with the system wide device types that driverfs will provide.
>
> 2. uid - Since topology and discovery order of hardware can change, the
> driverfs path names to a device are also subject to change. To
> easily identify a device I think it's important that the driverfs
> bus implementations be responsible for create a unique identifier.
>
> Since each bus and the devices attached to it will have varying
> capabilities for identifying themselves the contents for this file
> should probably be a variable length string.
>
> Even for older devices that can't do a great job of providing info to
> uniquely identify themselves, the driverfs tree provides the nice
> topological context to fall back upon that allows at least as
> good of a job to be done as we do today.
>
> The scsi patch currently creates uid info from the INQUIRY evpd pages
> and makes it available in the name file. I would prefer to see a
> new standard uid file and let the name file contain a descriptive
> (non-unique) name.
>
> 3. kdev - To create/manage/interface with the device node we need to know the
> kdev.
>
> Because of coldplugging this information should be available in each driverfs
> device directory. Also, adding the driverfs path name on /sbin/hotplug
> events and allowing the consumer to retrieve the info from the filesystem might
> help simplify some of these implementations too.
>
> The devnaming utility that is based on this strategy is available at
> http://www-124.ibm.com/devreg/
>
> I'd welcome any thoughts or suggestions.
It will probably take a few iterations before we get
close to an "approved" naming model :-)
So people have some idea what this patch generates, here
is my system's "/proc/scsi/scsi" followed by a "du -a"
at the top of the driverfs tree:
$ cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: FUJITSU Model: MAM3184MP Rev: 0105
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 09 Lun: 00
Vendor: SEAGATE Model: ST318451LW Rev: 0003
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi3 Channel: 00 Id: 00 Lun: 00
Vendor: Linux Model: scsi_debug Rev: 0003
Type: Direct-Access ANSI SCSI revision: 03
$ du -a
...
0 ./bus/usb
0 ./bus/scsi/drivers/sr
0 ./bus/scsi/drivers/sg
0 ./bus/scsi/drivers/sd # empty directory
0 ./bus/scsi/drivers
0 ./bus/scsi/devices/3:0:0:0:disc # symlinks across to "root" subtree
0 ./bus/scsi/devices/3:0:0:0:gen
0 ./bus/scsi/devices/3:0:0:0
0 ./bus/scsi/devices/1:0:9:0:gen
0 ./bus/scsi/devices/1:0:0:0:gen
0 ./bus/scsi/devices/1:0:9:0:p7
0 ./bus/scsi/devices/1:0:9:0:p6
0 ./bus/scsi/devices/1:0:9:0:p5
0 ./bus/scsi/devices/1:0:9:0:p4
0 ./bus/scsi/devices/1:0:9:0:p3
0 ./bus/scsi/devices/1:0:9:0:p2
0 ./bus/scsi/devices/1:0:9:0:p1
0 ./bus/scsi/devices/1:0:9:0:disc
0 ./bus/scsi/devices/1:0:0:0:p7
0 ./bus/scsi/devices/1:0:0:0:p6
0 ./bus/scsi/devices/1:0:0:0:p5
0 ./bus/scsi/devices/1:0:0:0:p4
0 ./bus/scsi/devices/1:0:0:0:p3
0 ./bus/scsi/devices/1:0:0:0:p2
0 ./bus/scsi/devices/1:0:0:0:p1
0 ./bus/scsi/devices/1:0:0:0:disc
0 ./bus/scsi/devices/1:0:9:0
0 ./bus/scsi/devices/1:0:0:0
0 ./bus/scsi/devices
0 ./bus/scsi
....
0 ./bus/pci/devices/00:0c.1 # symlinks, Tekram dual controller
0 ./bus/pci/devices/00:0c.0
....
0 ./bus/pci
0 ./bus
# scsi_debug "virtual" host bubbles to the top of "root"
# hierarchy because it has no "parent" bus type (i.e. it
# isn't pci). Why is the <h,c,t,l> given twice?
0 ./root/scsi3/3:0:0:0/3:0:0:0:disc/kdev
0 ./root/scsi3/3:0:0:0/3:0:0:0:disc/type
0 ./root/scsi3/3:0:0:0/3:0:0:0:disc/power
0 ./root/scsi3/3:0:0:0/3:0:0:0:disc/name # S1234Linuxdisc
0 ./root/scsi3/3:0:0:0/3:0:0:0:disc
0 ./root/scsi3/3:0:0:0/3:0:0:0:gen/kdev
0 ./root/scsi3/3:0:0:0/3:0:0:0:gen/type
0 ./root/scsi3/3:0:0:0/3:0:0:0:gen/power
0 ./root/scsi3/3:0:0:0/3:0:0:0:gen/name # S1234Linuxgeneric
0 ./root/scsi3/3:0:0:0/3:0:0:0:gen
0 ./root/scsi3/3:0:0:0/type
0 ./root/scsi3/3:0:0:0/power
0 ./root/scsi3/3:0:0:0/name # S1234Linux
0 ./root/scsi3/3:0:0:0
0 ./root/scsi3/power
0 ./root/scsi3/name # scsi_debug, Version: 1.59 ....
0 ./root/scsi3
0 ./root/pci0/00:0d.0/resources
0 ./root/pci0/00:0d.0/irq
....
0 ./root/pci0/00:0c.1/scsi2/power
0 ./root/pci0/00:0c.1/scsi2/name # sym-2.1.16a
0 ./root/pci0/00:0c.1/scsi2
0 ./root/pci0/00:0c.1/resources
0 ./root/pci0/00:0c.1/irq
0 ./root/pci0/00:0c.1/power
0 ./root/pci0/00:0c.1/name # PCI device 1000:0020
0 ./root/pci0/00:0c.1
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/kdev
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/type
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/power
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/name
# S3CC01TTG000071033QEASEAGATEgeneric
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/kdev
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/type
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/power
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/name
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7
...
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/kdev
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/type
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/power
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/name
# S3CC01TTG000071033QEASEAGATEpart1
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/kdev
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/type
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/power
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/name
# S3CC01TTG000071033QEASEAGATEdisc
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/type
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/power
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0/name
# S3CC01TTG000071033QEASEAGATE
0 ./root/pci0/00:0c.0/scsi1/1:0:9:0
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/kdev
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/type
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/power
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/name
# SUKS0P1B009PFFUJITSUgeneric
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/kdev
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/type
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/power
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/name
# SUKS0P1B009PFFUJITSUpart7
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p6/kdev
....
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/kdev
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/type
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/power
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/name
# SUKS0P1B009PFFUJITSUpart1
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/kdev
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/type
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/power
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/name
# SUKS0P1B009PFFUJITSUdisc
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/type
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/power
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0/name
# SUKS0P1B009PFFUJITSU
0 ./root/pci0/00:0c.0/scsi1/1:0:0:0
0 ./root/pci0/00:0c.0/scsi1/power
0 ./root/pci0/00:0c.0/scsi1/name
# sym-2.1.16a
0 ./root/pci0/00:0c.0/scsi1
0 ./root/pci0/00:0c.0/resources
0 ./root/pci0/00:0c.0/irq
0 ./root/pci0/00:0c.0/power
0 ./root/pci0/00:0c.0/name
0 ./root/pci0/00:0c.0
....
0 ./root/pci0/00:04.1/ata@01/power
0 ./root/pci0/00:04.1/ata@01/name # ATA/ATAPI Host-Channel
0 ./root/pci0/00:04.1/ata@01
It would be useful if Martin could show us one of his ATA
driverfs trees.
Patrick mentioned that we can soon expect these directories:
/driverfs/class/disk
/driverfs/class/tape
/driverfs/class/cd (or cd-dvd, or ...)
and perhaps
/driverfs/class/misc
for those nasty devices (e.g. tape robots and storage enclosures)
that need pass through drivers like sg.
The "/driverfs/class/disk"
directory would contain all attached disks (i.e.
ATA, SCSI, USB ...) with enumerated names (i.e.
"disk0", "disk1"). These enumerated names would be symlinks
to the device.
I'll start with one suggestion: perhaps "kdev" could
be replaced by two files: "major" and "minor".
Comments?
Doug Gilbert
[-- Attachment #2: scsi-driverfs_2524.diff.gz --]
[-- Type: application/x-gzip, Size: 8809 bytes --]
next prev parent reply other threads:[~2002-07-03 4:29 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 ` Douglas Gilbert [this message]
2002-07-03 14:34 ` [PATCH] driverfs scsi for 2.5.24 James Bottomley
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=3D227DB2.FD3D151@torque.net \
--to=dougg@torque.net \
--cc=dalecki@evision-ventures.com \
--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