Hi,
On 05/29/2013 12:08 AM, Tim Roberts wrote:
> Hans de Goede wrote:
>> I would like to give libusb using applications to os cached string
>> descriptors, so that those can be accessed without the need to open a
>> device and do io on it.
>
> The device is already open, because your API requires a libusb_device,
> right?
Nope, a libusb_device is just a software struct representing the info
we could get from the OS about the device without actually opening
it, or talking to the device. An opened device is represented by
a libusb_handle.
> So, you're saving the cost of one device descriptor read, and
> two string descriptor reads.
What I'm saving is opening the device (which under Linux requires rights
the app often won't have), and slow and expensive io to the device, which
includes waking it up from sleep, thus burning battery on portable devices.
> I don't know. The API is well-defined and simple enough, but it doesn't
> require any information private to the library.
It does require OS-specific knowledge, IE currently spice-gtk does:
#ifdef __linux__
/* <Sigh> libusb does not allow getting the manufacturer and product strings
without opening the device, so grab them directly from sysfs */
static gchar *spice_usbutil_get_sysfs_attribute(int bus, int address,
const char *attribute)
{
struct stat stat_buf;
char filename[256];
gchar *contents;
snprintf(filename, sizeof(filename), "/dev/bus/usb/%03d/%03d",
bus, address);
if (stat(filename, &stat_buf) != 0)
return NULL;
snprintf(filename, sizeof(filename), "/sys/dev/char/%d:%d/%s",
major(stat_buf.st_rdev), minor(stat_buf.st_rdev), attribute);
if (!g_file_get_contents(filename, &contents, NULL, NULL))
return NULL;
/* Remove the newline at the end */
contents[strlen(contents) - 1] = '\0';
return contents;
}
#endif
And in another part of the code:
#if __linux__
*manufacturer = spice_usbutil_get_sysfs_attribute(bus, address,
"manufacturer");
*product = spice_usbutil_get_sysfs_attribute(bus, address, "product");
#endif
It would be nice to have this abstracted away inside libusb.
> Would it be used often
> enough to justify including it in the library, as opposed to having it
> in a code sample? I can't judge that. I am, admittedly, a minimalist.
To me the direct frobbing of sysfs I'm doing in spice-gtk clearly is something
which belongs in libusb. This is the only sysfs frobbing spice-gtk does, all
the other sysfs handling is done through libusb.
Regards,
Hans
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
