Re: [PATCH] /proc/scsi/map

Re: [PATCH] /proc/scsi/map

[David Brownell]

> 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/disk1
> etc, 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/ipv4@10.42.135.99/... 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

Re: [PATCH] /proc/scsi/map

[Roman Zippel]

Hi,

On Sat, 22 Jun 2002, David Brownell wrote:

> Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... 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

Re: [PATCH] /proc/scsi/map

[Douglas Gilbert]

Roman Zippel wrote:
> 
> Hi,
> 
> On Sat, 22 Jun 2002, David Brownell wrote:
> 
> > Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... 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

Re: [PATCH] /proc/scsi/map

[Roman Zippel]

Hi,

On Sat, 22 Jun 2002, Douglas Gilbert wrote:

> 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

Re: [PATCH] /proc/scsi/map

[Nick Bellinger]

On Sat, 2002-06-22 at 11:24, David Brownell wrote:
> > 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/disk1
> > etc, 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/ipv4@10.42.135.99/... 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/ipv4@iSCSI.target.ip 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

Re: [PATCH] /proc/scsi/map

[David Brownell]

> 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

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> 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

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

On Sat, 22 Jun 2002, David Brownell wrote:

> > 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/disk1
> > etc, 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. 

> Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... 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. 

> 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)

[David Brownell]

 > 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.

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).


 > 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)

[Patrick Mochel]

> 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. 

> - 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)

[David Brownell]

>>- 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. 

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? :)


>>- 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)

[Patrick Mochel]

On Tue, 25 Jun 2002, David Brownell wrote:

> >>- 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. 
> 
> 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? :)

Hrm, they do appear to be out of sync. Thanks for pointing that out. 

> 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

Re: [PATCH] /proc/scsi/map

[David Brownell]

>>Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... 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

Re: [PATCH] /proc/scsi/map

[Nick Bellinger]

On Tue, 2002-06-25 at 11:49, David Brownell wrote:
> >>Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... 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?

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. 

> 
> 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?  

> 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

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> > 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?  

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

Re: [PATCH] /proc/scsi/map

[Pavel Machek]

Hi!

> >>Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... 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

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
-- 
(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