[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