[rss]

Patch for usb_modeswitch. Allow to directly use libusb-1.0 without compat library.

• http://code.google.com/p/wl500g/source/ ... sb10.patch
  http://code.google.com/p/wl500g/source/ ... mize.patch

Now for usb_modeswitch 1.1.9. Also available patches for previous versions of usb_modeswitch.

[rss]

Dear Josua,


First of all, thank you for usb_modeswitch, which uses libusb-0.1.

Latest release libusb-0.1.12 dated 2006-03-04, latest version of libusb-compat - 2009-07-09.


Nowadays, it’s obvious that libusb-0.1 is obsolete and forbidden, in in widely used Linux-distributives at least.

There are no applications that depend on libusb-0.1 or use libusb-compat-0.1, besides usb_modeswitch.

The situation could be ok, but we use embedded Linux where the size of rootfs is limited by hw flash, so it should be as small as possible, libusb-compat only for usb_modeswitch is kinda luxury.



Nearly one year ago we sent you patch for native libusb-1.0 support without compat library usage. It allows to conditionally build application either with libusb-0.1 or libusb-1.0.

Since we still support our patches locally, we suggest to implement official libusb-1.0 support.

If you don’t mind and have no rejections, we will clean up the things according your comments and exclude libusb wrappers.



Thank you in advance,

WL500g Team

http://wl500g.googlecode.com

[Josh]

I'm thinking about libusb1-only support once in a while.

Unfortunately, the libusb situation is not so clear when we look at the smaller distributions and include some older ones which may still be in use. This includes for example Xandros (eeepc) or CentOS which update slowly or not at all anymore. Then there are distros like Puppy and friends which still have the original libusb0 in their basic installation.

My intention was always to be as inclusive as possible with the binary part of usb_modeswitch. With a switch to libusb1 I would lose more than I would gain. Obviously, upward compatibility is possible, downward is not.

So, even if I was somewhat torn about the issue, I decided not to make the move.

What I can offer you though is to revise the current code and try to make it a little more "patch-friendly". I'll have a look into your patches.

BTW, I don't think the age of the original libusb0 is an issue. It's extremely stable in my experience. Also, version 0 is still used in current distributions; this for example gives you the packages of Fedora 15 that depend on libusb0:
http://rpm.pbone.net/index.php3?stat=3& ... &field[]=6

[theMIROn]

My intention was always to be as inclusive as possible with the binary part of usb_modeswitch. With a switch to libusb1 I would lose more than I would gain. Obviously, upward compatibility is possible, downward is not.
So, even if I was somewhat torn about the issue, I decided not to make the move.

Josh, nobody told about to drop libusb0.1 support, we suggested add native libusb1.0 support. It's functionality gain, not loss.

What I can offer you though is to revise the current code and try to make it a little more "patch-friendly". I'll have a look into your patches.

What do you think about autotools usage?
It'll be quite easy to check for installed libusb1, libusb0 and build against the first one found.

BTW, I don't think the age of the original libusb0 is an issue. It's extremely stable in my experience. Also, version 0 is still used in current distributions; this for example gives you the packages of Fedora 15 that depend on libusb0:
http://rpm.pbone.net/index.php3?stat=3& ... &field[]=6

there might be something really wrong with FC, because have no idea how can wine, vlc, sane have libusb 0.1 deps.

[Josh]

I did some more thinking - maybe I'll just add a simple "define" and macros in the code to support both versions.

Regarding autotools, at the moment I consider it "overkill" for just one dependency. If I continue to have a say, things will stay as simple as possible. Call me old-fashioned ...

[theMIROn]

I did some more thinking - maybe I'll just add a simple "define" and macros in the code to support both versions.

Regarding autotools, at the moment I consider it "overkill" for just one dependency. If I continue to have a say, things will stay as simple as possible. Call me old-fashioned ...

sure, in both cases, define macros are used, even now.
the question, imo, only in specifying the libusb version to be compiled against.
from this point of view, autotools will do their job flawlessy, for old-fashioned (c) way, we could just check header usb.h vs libusb.h

[gesp]

Just for information.
In 2010, usbutils switched in version 001 to require only libusb-1.0.
So actually for many distrib, usb-modeswitch is the only package that still require the old libusb-0.1. That add 17kb(unstripped) of bloat.

[Josh]

I was not able to include dual library support for the latest release. There were too many pressing issues to address.

I did not forget it, though. I have already started on a different branch; let's focus Christmas as a possible release target ...

[rss]

Thanks. But for the 1.2.0 version Leonid already updated the patch.
The link above is actual again.

[ssuominen]

I'm thinking about libusb1-only support once in a while.

Unfortunately, the libusb situation is not so clear when we look at the smaller distributions and include some older ones which may still be in use. This includes for example Xandros (eeepc) or CentOS which update slowly or not at all anymore. Then there are distros like Puppy and friends which still have the original libusb0 in their basic installation.

My intention was always to be as inclusive as possible with the binary part of usb_modeswitch. With a switch to libusb1 I would lose more than I would gain. Obviously, upward compatibility is possible, downward is not.

So, even if I was somewhat torn about the issue, I decided not to make the move.

What I can offer you though is to revise the current code and try to make it a little more "patch-friendly". I'll have a look into your patches.

BTW, I don't think the age of the original libusb0 is an issue. It's extremely stable in my experience. Also, version 0 is still used in current distributions; this for example gives you the packages of Fedora 15 that depend on libusb0:
http://rpm.pbone.net/index.php3?stat=3& ... &field[]=6

Are you aware that libusbx upstream maintainers have refused to maintain libusb-compat and it's bit rotting and have been broken already twice by the libusbx changes?

http://libusbx.sourceforge.net/

[Josh]

Thanks for the hint! I'll look into it.

[rss]

We are still updating the patch for libusb1.0:
https://code.google.com/p/wl500g/source ... odeswitch/

[Josh]

Thanks for the reminder, rss.

I think that indeed the time has come to make the switch.

[Josh]

I've just released version 2.0.1.

There was the switch to libusb1.x and some serious clean-up attempts.

If there are any quirks when using it on other platforms - like routers - I'd be grateful for a report.