On 2012.05.23 03:17, Yves Arrouye wrote:
> I double-checked the actual OS X API (the 32 bits comes from one of
> their samples). It seems like the underlying object is actually an
> OSNumber, which is a wrapper for a kernel number of 8, 16, 32 or 64
OK, then at the very least we'll need something 64 bit in size, or a
pointer to something that can be 64 bit.
> Is the Windows string something that would map to a 64-bit
> number? It would seem it would be if I understand correctly the
> discussions about the device path being of depth 7 at most.
Well, unless you're talking about the port topological ID ("device is
plugged on port 1 of a hub that is plugged on port 3 of a hub that is
plugged on port 2 of an HCD that is mapped to bus #4"), which doesn't
uniquely identify a device and isn't what the OS uses, what we're
talking about is a device interface path, which on Windows is something
like: "\\.\USB#VID_045E&PID_0289#7&1ABB1A1B&0&1"
>> I am aware of at least one implementation that simply took a look at the
>> private part of the libusb(x) device struct (which is supposed to be
>> opaque) and just remapped a copy of that struct to pick the items that
>> were of interest for the app.
>
> I thought about that :) I thought there was enough value in the
> Location ID to actually ask for it (and I could contribute code too of
> course).
Well, the one scenario I currently see where this would be of use is
hotplug, which apparently is also what you have in mind, and since we
are going to provide a hotplug implementation that should render the
need for such a scenario obsolete, I''d like to make sure there is more
value than this in rushing to integrate the feature you advocate.
> Location ID is not related to hot plug. If you don't have hot
> plugging, devices are still in a given location in the USB device
> tree.
Agreed. But I'm still not seeing many scenarios outside of a custom
hotplug implementation where someone would want to use libusbx to get an
OS specific location ID, and then use their own mode of access to the
device. The whole point of the library is to be as generic as possible
and handle everything one would otherwise would have to implement using
the OS specific APIs, in order to communicate with an USB device.
Therefore, I'm not sure I see why someone would list a device with
libusbx for instance, and then say directly use the Windows WinUSB API
to issue transfers, when they can do the same with libusbx.
Granted, we are still missing some of the features that the OS provides,
such as hotplug, which means we haven't entirely completed our mandate,
but we'll get there.
> Why can't there be platform-independent topology and
> platform-dependent ways to describe a location in the topology?
Well, platform independent topology is what the current implementation
provides.
And I think that platform dependent topology, if you want to call it
that way, doesn't exactly belong with the previous feature, precisely
because it is platform dependent and we need to have some overview of
which scenarios such a feature would be used for, that don't duplicate
features that we're planning to provide in the library anyway.
We've had quite a few requests for platform independent topology data
(mostly port ID), which is why some of us feel it is important to
provide it, but so far there seems to be only one for a platform
dependent location ID.
> I really think that
> those two are two faces of the same concept: the location is where I
> am in the USB topology that libusbx is aware of. Whether that location
> is represented as a path, a unique hash of that path or a reasonably
> short "ID" (which could have been a unique hash; it just seems that
> the OSes have decided to make it more friendly to human decoding given
> they could) it's still where a device is in that topology.
Well, I think on Windows there's a bit more than just the topology to
generate the device interface path, though the location is also used to
generate the hash that you see as the last part of the path.
Still, considering that we already provide a platform agnostic means of
identifying the location of a device, it sounds prudent to want to see
how much demand we have for an OS specific ID, before deciding on
whether we want to add it to the API.
> I'm just
> arguing that taking the OS value when available is more prudent than
> spending time trying to reverse engineer the encoding of location ID.
> THAT would definitely take time away from better things.
I think I had a reference on how the hash from the Windows device
interface path is actually generated. I'll see if I can dig that up, as
someone actually went the trouble of reverse engineering it and it's
quite insightful...
> OS data might be of interest to different people. That is going to be
> a bigger effort (and is libusbx going to try to normalize the names of
> these data?) Location ID is indeed just one piece of data and since
> you were discussing topology I thought that was appropriate.
Yes, and all I'm saying is I'm not sure what the demand will be.
Obvioulsy, every app developer will have their own specific needs, some
of which they probably wouldn't mind if a library could satisfy instead
of the app. Then again, trying to figure out if a feature request is
only going to help that one user or a whole bunch of them, in order to
avoid implementing a stream of features that are really aimed at a
single specific usage is also something we need to consider. Hence the
reason why I currently think the feature is better left for discussion
with the 2.0 API.
> Assuming you still think Location ID is not related to the topology
> effort (or is, but would be better served by the bigger "OS data"
> goal) then I'll probably go with the "let's peak inside the internal
> of the library" for now, as this means my code will be "portable"
> [sic] against both libusb and libusbx (until the internals run away
> from me, in which case I may have to see if dumping the device path
> into a string, 2 hex bytes at a time, ).
That's what I would encourage you to do for now.
Regards,
/Pete
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
