[Libusbx-devel] Linux patches for 1.0.9 release

Pete Batard pete at akeo.ie
Tue Mar 27 12:33:21 EDT 2012


On 2012.03.27 14:18, Xiaofan Chen wrote:
> I do not like the name either. The original name lsusb also
> sucks since it conflicts with usbutils package's lsusb which is
> widely used under Linux.

Yeah, personally I'd have gone with lusb. Googling for it doesn't show a 
risk of conflict (apart from people mispelling lsusb) and as previously 
stated, I'm not sure we should worry about prefixing samples over 
conflict matters. And if someone objects that lusb is not descriptive 
enough, then we'll probably want to change xusb and dpfp as well.

But anyway, that's just a matter of personal preferences and not really 
something I want to blow out of proportions. Unless there's more than a 
couple people who'd like a name change, listdevs will do fine.

> I think the current listdevs example is a bit too weak, weaker than
> libusb-0.1's testlibusb example anyway.
> http://git.libusb.org/?p=libusb-compat-0.1.git;a=blob;f=examples/testlibusb.c;hb=HEAD;js=1

I agree with that. Simple samples are fine, but at the end of the day, 
they don't demonstrate much more than what what somebody could have 
figured out from reading the docs. All listdevs does, that is USB 
specific really, is call on libusb_get_device_list() and that's it.

> Can we just remove it and then create a libusb-1.0 version
> of testlibusb?

As long as it's "replace" rather than "remove", I don't really have any 
objection. I'd prefer not ending up with libusbx having one less sample 
for a time, regardless of how short.

And since we now have trac installed, with a nice roadmap [1], I have 
added this to the v1.0.10 planned tasklist.

With regards to the roadmap, needless to say, it currently reflects only 
my own personal outlook, is most likely missing much, and is  provided 
as a first instance of where I'd see us heading, in order to invite 
comments. As all roadmaps, things can and will get 
amended/replaced/shifted as we move along.

> On the other hand, xusb has similar functionality but the output
> does not seem to be as nice as testlibusb.

This could be improved as well. I must admit that xusb is tailored to 
suit my testing purposes, which is mostly the provision of basic control 
transfers (at least strings, more if available) for as many devices as 
possible. I haven't spent a lot of time on making its output nicer, and 
I'm quite open to suggestion there.

Regards,

/Pete

[1] https://sourceforge.net/apps/trac/libusbx/roadmap






More information about the libusbx mailing list