/proc/scsi/map
Quoted 5 lines
On the other hand there is the obvious fact that an iSCSI initiator driver is not attached to a bus, and assuming
/root/iSCSI.target/disk1etc, is out of the question. There is a real need for a solution to handle virtual devices (as stated your previous message) that are not assoicated with any physical connectors.
There are those who see the IP stack as a kind of logical bus ... :) It's just not tied any specific hardware interface; it's "multipathed" in some sense. Linking it to an eth0 entry in $DRIVERFS/root/pci0/00:10.0 would be wrong, since it can also be accessed through eth2.
Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup for iSCSI devices? Using whatever physical addressing the kernel uses there, which I assume wouldn't necessarily be restricted to ipv4. (And not exposing physical network topology -- routing! -- in driverfs.)
On a related topic ... if driverfs is going to be providing a nice unique ID for the controller ($DRIVERFS/root/pci0/00:02.0/02:0f.0/03:07.0 for Linus' behind-two-bridges case), why are people talking as if the SCSI layer's arbitrary "controller number" should still be getting pushed as part of user visible names?
That is, I'd sure hope the standard policy for assigning driverfs names would avoid _all_ IDs that are derived from enumeration order. Otherwise it'll be hard to store those names for (re)use by user mode tools.
To be sure, those IDs can still be exposed when needed, since in the "very big picture" attribute-based names end up being the only really scalable model. But putting unstable attributes into path names just causes trouble. (Much like putting device types in path names.) If they're really necessary (why?) driverfs makes it easy to expose them in better ways.
- Dave
Hi,
Quoted 3 lines · David Brownell
Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup for iSCSI devices? Using whatever physical addressing the kernel uses there, which I assume wouldn't necessarily be restricted to ipv4.
iSCSI devices are uniqely identified by its name. An iSCSI device can be reachable at multiple ip numbers or they can even change dynamically.
bye, Roman
Quoted 11 lines · Roman Zippel
Hi,
Quoted 3 lines · David Brownell
Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup for iSCSI devices? Using whatever physical addressing the kernel uses there, which I assume wouldn't necessarily be restricted to ipv4.
iSCSI devices are uniqely identified by its name. An iSCSI device can be reachable at multiple ip numbers or they can even change dynamically.
Roman,
Trying to clear up the nomenclature here, according to SAM-2 ( www.10.org ) target ports have mandatory "identifiers" and optional "names". The WWUI in iSCSI is part of the target _identifier_. SAM-2 is pretty vague about "names" but it does note that for a logical unit, its _name_ may be reported in the Device Identification VPD page in an INQUIRY.
Doug Gilbert
Hi,
Quoted 7 lines · Douglas Gilbert
Trying to clear up the nomenclature here, according to SAM-2 ( www.10.org ) target ports have mandatory "identifiers" and optional "names". The WWUI in iSCSI is part of the target _identifier_. SAM-2 is pretty vague about "names" but it does note that for a logical unit, its _name_ may be reported in the Device Identification VPD page in an INQUIRY.
iSCSI currently specifies two types of names:
1. iSCSI Qualified Name: contains a date, domain and an arbitrary name, e.g. "iqn.2001-04.com.acme.diskarrays-sn-a8675309"
2. IEEE EUI-64 format: an IEEE assigned name, e.g. "eui.02004567A425678D"
bye, Roman
Quoted 11 lines · David Brownell
Quoted 5 lines
On the other hand there is the obvious fact that an iSCSI initiator driver is not attached to a bus, and assuming
/root/iSCSI.target/disk1etc, is out of the question. There is a real need for a solution to handle virtual devices (as stated your previous message) that are not assoicated with any physical connectors.There are those who see the IP stack as a kind of logical bus ... :) It's just not tied any specific hardware interface; it's "multipathed" in some sense. Linking it to an eth0 entry in $DRIVERFS/root/pci0/00:10.0 would be wrong, since it can also be accessed through eth2.
Quoted 6 lines
Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup for iSCSI devices? Using whatever physical addressing the kernel uses there, which I assume wouldn't necessarily be restricted to ipv4. (And not exposing physical network topology -- routing! -- in driverfs.)
Giving the IP stack its own directory (leaf?) under driverfs root sounds interesting enough and could have some potential uses, but in the case of iSCSI there are a few problems:
iSCSI Names (aka: iSCSI Qualified Names or IEEE EUI-64 names ) are world wide unique and are intended to stay with the iSCSI Node throughout its lifetime, regardless of IP/HBA/NIC/etc changes. Also an iSCSI session can include multiple TCP connections with each different IP addresses, so the format of $DRIVERFS/net/[email protected] is insufficent.
This reiterates the need for a sound logical device naming scheme that fits into driverfs without mucking up the basic structure. Not being a expert on naming, the least offensive format I can think with regard to iSCSI would be something along the lines of:
$DRIVERFS/virt/iscsi/iqn.2002-06.com.foo.super.turbo.disk.array.3543/disk0
being the iqn for an iSCSI Target node as viewed by an iSCSI Initiator node.
Nicholas Bellinger
Quoted 6 lines
This reiterates the need for a sound logical device naming scheme that fits into driverfs without mucking up the basic structure. Not being a expert on naming, the least offensive format I can think with regard to iSCSI would be something along the lines of:
$DRIVERFS/virt/iscsi/iqn.2002-06.com.foo.super.turbo.disk.array.3543/disk0
That could do the job, but I'll leave those discussions up to SCSI experts ... seems there are folk there who know something about the topic, unlike me ! :)
Perhaps such things will be discussed at OLS next week, not that I'll be there.
- Dave
Quoted 5 lines
This reiterates the need for a sound logical device naming scheme that fits into driverfs without mucking up the basic structure. Not being a expert on naming, the least offensive format I can think with regard to iSCSI would be something along the lines of:
The device model will not give devices default names. It will pass the responsibility to userspace, along with the path to the device via /sbin/hotplug. From the patch, the userspace agent can derive various things from the device's directory, including the device type and the UUID of the device. From this, userspace can look up what to name the device.
-pat
Quoted 10 lines · David Brownell
Quoted 5 lines
On the other hand there is the obvious fact that an iSCSI initiator driver is not attached to a bus, and assuming
/root/iSCSI.target/disk1etc, is out of the question. There is a real need for a solution to handle virtual devices (as stated your previous message) that are not assoicated with any physical connectors.There are those who see the IP stack as a kind of logical bus ... :) It's just not tied any specific hardware interface; it's "multipathed" in some sense. Linking it to an eth0 entry in $DRIVERFS/root/pci0/00:10.0 would be wrong, since it can also be accessed through eth2.
It's not wrong, it's just makes life interesting when you want accurately represent the presence of the device via both paths, or you want to deal with the removal or power management of the bridge device. That problem needs to be addressed; soon.
Quoted 5 lines
Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup for iSCSI devices? Using whatever physical addressing the kernel uses there, which I assume wouldn't necessarily be restricted to ipv4. (And not exposing physical network topology -- routing! -- in driverfs.)
You can very well use driverfs to expose those attributes, and is one of the things that we've been discussing at the kernel summit. driverfs will take over the world. But, I still think the device is best represented as a child of the phsysical network device.
Quoted 9 lines
On a related topic ... if driverfs is going to be providing a nice unique ID for the controller ($DRIVERFS/root/pci0/00:02.0/02:0f.0/03:07.0 for Linus' behind-two-bridges case), why are people talking as if the SCSI layer's arbitrary "controller number" should still be getting pushed as part of user visible names?
That is, I'd sure hope the standard policy for assigning driverfs names would avoid _all_ IDs that are derived from enumeration order. Otherwise it'll be hard to store those names for (re)use by user mode tools.
The bus_id of the device is intended to represent the bus-specific ID of the device, and is the name of the driverfs directory.
The name should user-friendly. It shouldn't be a unique name. Use something nice and pretty. If people need/want a UUID, add it to the bus-specific or type-specific structure, and export it via driverfs. It will eventually make it to the generic structure.
-pat
driverfs bus_id, name (was: [PATCH] /proc/scsi/map)
Quoted 2 lines
The
bus_idof the device is intended to represent the bus-specific ID of the device, and is the name of the driverfs directory.
Right, I was just commenting that the SCSI folk seem to like a particular historical usage (based on driver enumeration order) that'd seem good to do away with ... since it's not necessary (given the _real_ bus-specific ID from their parent device) and has _always_ been problematic (those enumeration-related IDs can change unexpectedly).
Quoted 2 lines
The name should user-friendly. It shouldn't be a unique name. Use something nice and pretty.
I've been wondering about that. Right now PCI and USB both use fairly unfriendly/unpretty values in device.name ... "{PCI,USB} device VVVV:PPPP".
Let me make sure I understand you right here, by examples of two changes I'd like to see. Correct me if these seem wrong:
- It'd be more appropriate for PCI devices to copy pci_device.name into device.name and get the user-friendly names from the PCI device name database (when available), and only fallback to those nasty strings when the more user-friendly names aren't available.
- Likewise it'd be more appropriate for USB devices to take the descriptive strings from the devices, like "Philips USB Digital Speaker System", than "USB device 0471:0104".
In both cases the current strings might make reasonable fallbacks for the case when something better isn't available. But as examples, I don't think they match a "user friendly, pretty" model ... :)
Would it be appropriate for device drivers to set the "name" in some cases, or is that something you'd only expect bus drivers to be setting up (once, and read-only)?
Given that in one common usage the "bus_id" is the "true name" of those devices, I've thought that "description" might be a slightly better way identify that attribute. "Name" is a word with a thousand meanings, all of them context-dependent, and easily confused.
- Dave
Re: driverfs bus_id, name (was: [PATCH] /proc/scsi/map)
Quoted 11 lines
I've been wondering about that. Right now PCI and USB both use fairly unfriendly/unpretty values in device.name ... "{PCI,USB} device VVVV:PPPP".
Let me make sure I understand you right here, by examples of two changes I'd like to see. Correct me if these seem wrong:
- It'd be more appropriate for PCI devices to copy pci_device.name into device.name and get the user-friendly names from the PCI device name database (when available), and only fallback to those nasty strings when the more user-friendly names aren't available.
That is what happens with PCI devices. They're not appearing as meaningful names probably because CONFIG_PCI_NAMES isn't set. Whether or not that information belongs in the kernel is another debate.
I believe the SCSI people mentioned something about being able to set those from userspace. I'm not opposed to such an idea. You just need a writable name file.
Quoted 3 lines
- Likewise it'd be more appropriate for USB devices to take the descriptive strings from the devices, like "Philips USB Digital Speaker System", than "USB device 0471:0104".
Those are in the devices themselves, right? There is nothing stopping the USB people from doing that... ;)
-pat
Re: driverfs bus_id, name (was: [PATCH] /proc/scsi/map)
Quoted 7 lines
Quoted 4 lines
- It'd be more appropriate for PCI devices to copy pci_device.name into device.name and get the user-friendly names from the PCI device name database (when available), and only fallback to those nasty strings when the more user-friendly names aren't available.
That is what happens with PCI devices. They're not appearing as meaningful names probably because
CONFIG_PCI_NAMESisn't set. Whether or not that information belongs in the kernel is another debate.
ERm ... it wasn't on the systems I looked at. CONFIG_PCI_NAMES has clearly been set, but the names were the user-unfriendly style. And yet I know the kernel has them accessible, since they're presented by the USB layer and by /proc/pci. But not in driverfs.
I now see some code (presumably yours) to set those two fields to be identical, in pci_scan_device(), but the useful description is instead set in pci_scan_slot(). Presumably this is a case of various init paths in PCI not wholly agreeing with each other; maybe pci_name_device() should set both name/description fields instead of only the one. (Though ... why have two copies? :)
Quoted 6 lines
Quoted 3 lines
- Likewise it'd be more appropriate for USB devices to take the descriptive strings from the devices, like "Philips USB Digital Speaker System", than "USB device 0471:0104".
Those are in the devices themselves, right? There is nothing stopping the USB people from doing that... ;)
Good, I was just sanity checking ... since the PCI names really haven't worked to provide user-friendly names, and I couldn't tell if that was intentional. I can provide a patch for USB easily.
You didn't respond to the question about changing the identifier from "name" to be the more appropriate "description" ... is that because you're still thinking (it'd cost to change) or because you like using the (IMO ambiguous) identifier "name" there?
- Dave
Re: driverfs bus_id, name (was: [PATCH] /proc/scsi/map)
Quoted 15 lines · David Brownell
Quoted 9 lines
Quoted 4 lines
- It'd be more appropriate for PCI devices to copy pci_device.name into device.name and get the user-friendly names from the PCI device name database (when available), and only fallback to those nasty strings when the more user-friendly names aren't available.
That is what happens with PCI devices. They're not appearing as meaningful names probably because
CONFIG_PCI_NAMESisn't set. Whether or not that information belongs in the kernel is another debate.ERm ... it wasn't on the systems I looked at.
CONFIG_PCI_NAMEShas clearly been set, but the names were the user-unfriendly style. And yet I know the kernel has them accessible, since they're presented by the USB layer and by/proc/pci. But not in driverfs.
Quoted 6 lines
I now see some code (presumably yours) to set those two fields to be identical, in
pci_scan_device(), but the useful description is instead set inpci_scan_slot(). Presumably this is a case of various init paths in PCI not wholly agreeing with each other; maybepci_name_device()should set both name/description fields instead of only the one. (Though ... why have two copies? :)
Hrm, they do appear to be out of sync. Thanks for pointing that out.
Quoted 4 lines
You didn't respond to the question about changing the identifier from "name" to be the more appropriate "description" ... is that because you're still thinking (it'd cost to change) or because you like using the (IMO ambiguous) identifier "name" there?
That's what the name field is - the ascii description of the device. I understand that "description" is more obvious, so I'll consider the change.
-pat
Quoted 8 lines
Quoted 5 lines
Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup for iSCSI devices? Using whatever physical addressing the kernel uses there, which I assume wouldn't necessarily be restricted to ipv4. (And not exposing physical network topology -- routing! -- in driverfs.)
You can very well use driverfs to expose those attributes, and is one of the things that we've been discussing at the kernel summit. driverfs will take over the world. But, I still think the device is best represented as a child of the phsysical network device.
Which one? I'd certainly hope that drivers wouldn't have to choose which of the various network interfaces to register under, or register under every network interface concurrently. (Or only the ones they might conceivably be routed to go out on...) Given a bonded network link (going out over multiple physical drivers) that'd get hairy. And what about devices that host several logical interfaces? Or when the interfaces get moved to some other device?
That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more sensible in such cases. Which is not to say it's without additional issues (like how to establish/maintain driver linkages that are DAGs not single parent trees) but it wouldn't require drivers to dig as deeply into lower levels of their stack. (And some network interfaces might well live in such a non-physical tree, not just iSCSI...)
I think that problem wouldn't quite be isomorphic to multipath access to devices, though it seems to be related. "Driver stacking" is an area that "driverfs" doesn't seem to address quite yet ... not needed in the simpler driver scenarios, so that's what I'd expect at this stage.
- Dave
Quoted 12 lines · David Brownell
Quoted 11 lines
Quoted 5 lines
Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup for iSCSI devices? Using whatever physical addressing the kernel uses there, which I assume wouldn't necessarily be restricted to ipv4. (And not exposing physical network topology -- routing! -- in driverfs.)
You can very well use driverfs to expose those attributes, and is one of the things that we've been discussing at the kernel summit. driverfs will take over the world. But, I still think the device is best represented as a child of the phsysical network device.
Quoted 7 lines
Which one? I'd certainly hope that drivers wouldn't have to choose which of the various network interfaces to register under, or register under every network interface concurrently. (Or only the ones they might conceivably be routed to go out on...) Given a bonded network link (going out over multiple physical drivers) that'd get hairy. And what about devices that host several logical interfaces? Or when the interfaces get moved to some other device?
I hate to kick the already deceased horse but..
This appears to be one of the larger problems that nobody (aside from this thread :) seems to be raising. I understand Pat's logic of wanting to keep the logical device a child of the network card, but in many situations (espically the enterprise ones with regard multipathed IP storage, along with David's examples above) I just dont see how that can be done correctly in keeping all the prementioned virtual devices part of the network device's directory in the tree.
Quoted 8 lines
That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more sensible in such cases. Which is not to say it's without additional issues (like how to establish/maintain driver linkages that are DAGs not single parent trees) but it wouldn't require drivers to dig as deeply into lower levels of their stack. (And some network interfaces might well live in such a non-physical tree, not just iSCSI...)
I am in complete agreement, from my little view of where driverfs currently stands a non-physical tree is going to have to happen sooner or later, why not now?
Quoted 7 lines
I think that problem wouldn't quite be isomorphic to multipath access to devices, though it seems to be related. "Driver stacking" is an area that "driverfs" doesn't seem to address quite yet ... not needed in the simpler driver scenarios, so that's what I'd expect at this stage.
- Dave
Thanks!
Nicholas Bellinger
Quoted 9 lines
Quoted 8 lines
That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more sensible in such cases. Which is not to say it's without additional issues (like how to establish/maintain driver linkages that are DAGs not single parent trees) but it wouldn't require drivers to dig as deeply into lower levels of their stack. (And some network interfaces might well live in such a non-physical tree, not just iSCSI...)
Quoted 3 lines
I am in complete agreement, from my little view of where driverfs currently stands a non-physical tree is going to have to happen sooner or later, why not now?
No. The physical hierarchy in driverfs is meant to be as accurate as possible. Yes, it's idealistic, and at some point we might have to make a bit of an exception. But, I refuse to break that model yet.
-pat
Hi!
Quoted 20 lines
Quoted 11 lines
Quoted 5 lines
Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup for iSCSI devices? Using whatever physical addressing the kernel uses there, which I assume wouldn't necessarily be restricted to ipv4. (And not exposing physical network topology -- routing! -- in driverfs.)
You can very well use driverfs to expose those attributes, and is one of the things that we've been discussing at the kernel summit. driverfs will take over the world. But, I still think the device is best represented as a child of the phsysical network device.
Which one? I'd certainly hope that drivers wouldn't have to choose which of the various network interfaces to register under, or register under every network interface concurrently. (Or only the ones they might conceivably be routed to go out on...) Given a bonded network link (going out over multiple physical drivers) that'd get hairy. And what about devices that host several logical interfaces? Or when the interfaces get moved to some other device?
Quoted 5 lines
That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more sensible in such cases. Which is not to say it's without additional issues (like how to establish/maintain driver linkages that are DAGs not single parent trees) but it wouldn't require drivers to dig as deeply into
Quoted 1 line
Quoted 1 line
lower
Hmm, are dags enough?
I mean, cycles exist in IP based networks, and I don't see a reason why it could not exist with some kind of advanced fibrechannel.
Pavel
Signature · 2 lines
(about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
Hi!
Quoted 20 lines
Quoted 11 lines
Quoted 5 lines
Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup for iSCSI devices? Using whatever physical addressing the kernel uses there, which I assume wouldn't necessarily be restricted to ipv4. (And not exposing physical network topology -- routing! -- in driverfs.)
You can very well use driverfs to expose those attributes, and is one of the things that we've been discussing at the kernel summit. driverfs will take over the world. But, I still think the device is best represented as a child of the phsysical network device.
Which one? I'd certainly hope that drivers wouldn't have to choose which of the various network interfaces to register under, or register under every network interface concurrently. (Or only the ones they might conceivably be routed to go out on...) Given a bonded network link (going out over multiple physical drivers) that'd get hairy. And what about devices that host several logical interfaces? Or when the interfaces get moved to some other device?
Quoted 5 lines
That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more sensible in such cases. Which is not to say it's without additional issues (like how to establish/maintain driver linkages that are DAGs not single parent trees) but it wouldn't require drivers to dig as deeply into
Quoted 1 line
Quoted 1 line
lower
Hmm, are dags enough?
I mean, cycles exist in IP based networks, and I don't see a reason why it could not exist with some kind of advanced fibrechannel.
Pavel
Signature · 2 lines
(about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa