Oliver Neukum wrote:
What is specific about USB in that regard?
It would seem to me that you'd better export something that stays
the same across reboot, but don't call it USB_something.
I'm not sure I understand your question or implication.
Why shouldn't USB-specific identifiers be USB_something?

The interpretation is specific to USB.
But having a physical path that survives reboot is a problem all
bus systems have.
I'd more call it a "basic characteristic" than a problem.  Even
with multi-pathed I/O frameworks there are physical paths (more
than one!) which are stable until the system gets re-cabled.

I certainly wouldn't object to having a more generic solution
to that issue, but Greg and Pat haven't been amenable to having
driverfs address the issue generically.


There are as I see it, two ways of recognising a device,
a unique identifier and physical path. User space may want
both or one of them. You cannot know thus should export both.
Certainly I agree with that perspective:  support policy options
for user space.  Physical path being one, since every device
has such a path.

But "unique" identifiers are only "unique in context", and
the kernel may not know all of the ones user space cares
about.  It can expose $DEVPATH/serial (which isn't always
even unique!), but for example SCSI devices may have
a few other "unique" IDs available.

- Dave


Yet the most basic function of such a 'permanent path' is
entering it into a table to tell knew devices apart from devices
already known which an old configuration is available for.
That is not specific to USB, because you can treat the exported
information as an opaque token that you simply compare to.


DEVPATH indeed seems to be an inferior choice, because you
need extra knowledge to extract a permanent path out of it.
Knowledge you can't generally have, too:  which bus-specific
parts of DEVPATH have that information (if any).

Yes, taking it is a layering violation.

	Regards
		Oliver






-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to