Thanks everyone for your input again. I've made the changes suggested, and
would appreciate this being applied to Linus' and Alan's trees. This is
necessary for solving the "what disk does BIOS think is my boot disk"
problem on IA-64, and I hope to extend it to IA-32 when BIOSs permit.
Jeff Garzik recommended the IOCTL return pci_dev::slot_name, so now it does,
and this simplifies the ioctl greatly.
Doug Gilbert recommended wrapping things in #ifdef's, so I created a new
CONFIG_SCSI_PCI_INFO define.
Patches against 2.4.4-pre6 are available at http://domsch.com/linux/scsi/.
linux-2.4.4-pre6-scsi-pci-info-010424.patch - Adds the IOCTL and
CONFIG_SCSI_PCI_INFO, and touches a bunch of SCSI drivers.
scsimon_243_1_pci-010424.patch - Changes scsimon Makefile and sm_test.c to
support this.
scsimon_243_1_pci_driver.patch - Changes scsimon.[ch] to support this.
When this goes in, I request the assistance of the SCSI driver maintainers.
I've changed quite a few drivers, but couldn't easily see how to change a
few others. I am bcc'ing the maintainers of drivers I changed or need help
from.
Drivers that I changed:
3w-xxxx.c
AM53C974.c
advansys.c
aic7xxx_old.c
atp870u.c
cpqfcTSinit.c
dmx3191d.c
fdomain.c
gdth.c
ips.c
ncr53c8xx.c
qla1280.c
qlogicfc.c
qlogicisp.c
sym53c8xx.c
tmscsim.c
megaraid.c
53c7,8xx.c
pci2000.c
pci2220i.c
Non-trivial drivers that I didn't change, but request their
maintainers do so:
BusLogic.c
aic7xxx.c
eata.c
eata_dma.c
eata_pio.c
ini9100u.c
inia100.c
Drivers I didn't need to change (they're not PCI devices, best as I can
tell):
NCR53C9x.c
NCR53c406a.c
aha152x.c
aha1542.c
aha1740.c
esp.c
fd_mcs.c
ibmmca.c
ide-scsi.c
imm.c
in2000.c
mac53c94.c
mesh.c
ppa.c
qlogicfas.c
qlogicpti.c
sgiwd93.c
sim710.c
sym53c416.c
u14-34f.c
ultrastor.c
53c7xx.c
a2091.c
a3000.c
atari_scsi.c
dtc.c
fcal.c
g_NCR5380.c
gvp11.c
mac_scsi.c
mvme147.c
pas16.c
pluto.c
psi240i.c
seagate.c
sun3_scsi.c
t128.c
wd7000.c
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
http://www.dell.com/linux
Matt Domsch writes:
> Thanks everyone for your input again. I've made the changes suggested, and
> would appreciate this being applied to Linus' and Alan's trees. This is
> necessary for solving the "what disk does BIOS think is my boot disk"
> problem on IA-64, and I hope to extend it to IA-32 when BIOSs permit.
>
> Jeff Garzik recommended the IOCTL return pci_dev::slot_name, so now it does,
> and this simplifies the ioctl greatly.
> Doug Gilbert recommended wrapping things in #ifdef's, so I created a new
> CONFIG_SCSI_PCI_INFO define.
As I said to Matt privately, I think adding this kind of ioctl is
ugly. We have enough ioctl's as it is. All Matt is trying to do is to
access drives via location, so exposing location-based device nodes
via devfs is IMNSHO cleaner.
The plan I have (which I hope to get started on soon, now that I'm
back from travels), is to change /dev/scsi/host# from a directory into
a symbolic link to a directory called: /dev/bus/pci0/slot1/function0.
Thus, to access a partition via location, one would use the path:
/dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
At 3:59 PM -0600 4/24/01, Richard Gooch wrote:
>The plan I have (which I hope to get started on soon, now that I'm
>back from travels), is to change /dev/scsi/host# from a directory into
>a symbolic link to a directory called: /dev/bus/pci0/slot1/function0.
>Thus, to access a partition via location, one would use the path:
>/dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3.
A minor PCI terminology point: PCI buses are subdivided into devices, not (necessarily) slots. So, for example, a multiple-device PCI card (say, two SCSI controllers) might have a PCI bridge creating a new bus, and two devices (not slots) on that bus. (It could alternatively be implemented as a single device with two functions, given a dual-interface chip, but not necessarily.)
So a better name would be /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 (taking the liberty of abbreviating some of the other names).
How, if at all, would RAID devices, using more than one physical device, or SCSI bus, or PCI card, fit into this naming scheme?
--
/Jonathan Lundell.
Jonathan Lundell writes:
> At 3:59 PM -0600 4/24/01, Richard Gooch wrote:
> >The plan I have (which I hope to get started on soon, now that I'm
> >back from travels), is to change /dev/scsi/host# from a directory into
> >a symbolic link to a directory called: /dev/bus/pci0/slot1/function0.
> >Thus, to access a partition via location, one would use the path:
> >/dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3.
>
> A minor PCI terminology point: PCI buses are subdivided into
> devices, not (necessarily) slots. So, for example, a multiple-device
> PCI card (say, two SCSI controllers) might have a PCI bridge
> creating a new bus, and two devices (not slots) on that bus. (It
> could alternatively be implemented as a single device with two
> functions, given a dual-interface chip, but not necessarily.)
>
> So a better name would be
> /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 (taking the liberty of
> abbreviating some of the other names).
Sure. I haven't made a decision on the names yet. I was just sketching
out the idea.
> How, if at all, would RAID devices, using more than one physical
> device, or SCSI bus, or PCI card, fit into this naming scheme?
Same as it does now. There's the underlying devices, and then the meta
devices, which are under /dev/md.
BTW: please fix your mailer to do linewrap at 72 characters. Your
lines are hundreds of characters long, and that's hard to read.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
At 10:31 PM -0600 2001-04-26, Richard Gooch wrote:
>BTW: please fix your mailer to do linewrap at 72 characters. Your
>lines are hundreds of characters long, and that's hard to read.
Sorry for the inconvenience. There are a lot of reasons why I believe
it's properly a display function to wrap long lines, and that an MUA
has no business altering outgoing messages (one on-topic reason being
that patches get screwed up by inserted newlines), but I grant that
there are broken clients out there that can't or won't or don't wrap
at display time.
On the subject of the Subject, Jeff Garzik recently (21 March)
suggested adding geographic information to the ethtool interface,
pci_dev->slot_name in the case of a PCI-based interface. There's
something to be said for having a uniform method of identifying the
location of devices, or at least a uniform parsable format. (A
potential shortcoming of Jeff's scheme, perhaps, is that it needs to
identify the slot_name as a PCI slot_name, though I could be missing
something there.)
Consider, instead of /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3
something like
/dev/bus/pci0d1f0/scsi0t1l2p3
or
/dev/bus/pci0:d1:f0/scsi0:t1:l2:p3
Are there systems with more than one PCI bus numbering domain? I
don't see why not, in principle (not an issue for SCSI, which doesn't
have bus numbering). So perhaps:
/dev/bus/pci0:b0:d1:f0/scsi0:t1:l2:p3
which distinguishes between PCI domains and PCI bus numbers.
At 10:31 PM -0600 2001-04-26, Richard Gooch wrote:
>Sure. I haven't made a decision on the names yet. I was just sketching
>out the idea.
It's a good idea. Just feedback on the initial sketch.
A related idea would be the ability to translate from a logical PCI
slot number, as above, and a physically meaningful description that
the user could use to identify an actual slot. Unfortunately the
proper place for such a translation function is in the
(hardware-specific) BIOS.
--
/Jonathan Lundell.
Jonathan Lundell writes:
> On the subject of the Subject, Jeff Garzik recently (21 March)
> suggested adding geographic information to the ethtool interface,
> pci_dev->slot_name in the case of a PCI-based interface. There's
> something to be said for having a uniform method of identifying the
> location of devices, or at least a uniform parsable format. (A
> potential shortcoming of Jeff's scheme, perhaps, is that it needs to
> identify the slot_name as a PCI slot_name, though I could be missing
> something there.)
>
> Consider, instead of /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3
> something like
>
> /dev/bus/pci0d1f0/scsi0t1l2p3
> or
> /dev/bus/pci0:d1:f0/scsi0:t1:l2:p3
Nope. Linus hates the idea of "compressed" names. He wants them to be
obvious at first glance. My original devfs patch (before it went into
the kernel) had compressed names, and he made me change them (there
were other changes as well). I know it's a bit much to type in, but
he's probably right. If people need it, I can add compressed names to
devfsd, just like I did to preserve the names in the original devfs
patch.
> A related idea would be the ability to translate from a logical PCI
> slot number, as above, and a physically meaningful description that
> the user could use to identify an actual slot. Unfortunately the
> proper place for such a translation function is in the
> (hardware-specific) BIOS.
Nope. It's cleaner to do this in a vendor-specific "fixup" layer. Alan
asked me a similar question privately, so I've included my reponse to
his email (quoting bits of his email for context) below. In his reply,
Alan said "it makes sense". I take that as a good omen.
=========
> How do you intend to handle pci busses that are below other busses - eg gsc
> /dev/bus/gsc/bus/pci0/ .. ?
> Im just thinking it gets very cumbersome.
It could. And if you play with the upcoming SGI IA-64 boxes, where
they have a deep /dev/hw, it would appear even more so. However, I
came up with a scheme while I was visiting them after the workshop,
which I believe will handle an arbitrarily complex vendor tree. I'm
actually quite proud of this idea :-)
The basic idea is that /dev/bus contains a *logical* enumeration of
all busses in the system. This contains the generic Linux view of
busses. We already have this enumeration within struct pci_dev and
friends.
Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0
into symlinks to something like /dev/hw/PBrick/00AA3415/bus1/pci3 (or
similar, I forget just how deep SGI's tree went).
This scheme is really just an extension of the approach Linus took in
the Great Name Change he forced upon me a year and a half ago. Back
then, he wanted /dev/discs to answer the question "what discs do I
have", and "/dev/scsi" to answer "what SCSI devices do I have, and
what's the layout". So now, I'm adding "/dev/bus" for "what logical
busses do I have" and "/dev/hw" for "what is the exact hardware
topology".
Where we have "generic" hardware (i.e. a vendor doesn't provide their
own PCI fixups), and there is a need to show the bus topology, we can
write generic fixups that parse the struct pci_dev and friends. For
example, most x86 machines would fall in this "generic" category.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]