[Y.J. Cao]

I have a problem for long time:
if the devices can work correctly by using only the binary file usb-modeswitch, why the developer give those scripts?
I am transplanting a 3G driver to arm paltform, the problem come to me when I read the Makefile in both usb-modeswitch-1.1.18 and the datafile.
I think the scripts are important, but I don't know how to use it.


thanks if any advices!
Y.J. Cao

[Josh]

Here is the "architecture" description:

• the binary "usb_modeswitch" depends only on libc and lbusb. It's quite portable, but users have to take care about the execution on the respective system (in many cases, no udev available). You can switch single devices with no problem using the right config file or command line.
• the "sh" script and the "tcl" script are very Linux-specific. They need the "usbfs" in the sys tree. Furthermore there is a Tcl shell/interpreter required. And of course all of it depends on "udev".
  With this "framework", ambiguities in device IDs are sorted out, every device will get the right switching configuration, the serial driver is loaded and bound if the device is not yet included in the source code, and a convenience link ("/dev/gsmmodem") is added which points to the correct port. In the ideal case, no user interaction is necessary except plugging in.

Unfortunately, there is no standard way on embedded devices how to handle hot-plug events.

[Y.J. Cao]

Here is the "architecture" description:

• the binary "usb_modeswitch" depends only on libc and lbusb. It's quite portable, but users have to take care about the execution on the respective system (in many cases, no udev available). You can switch single devices with no problem using the right config file or command line.
• the "sh" script and the "tcl" script are very Linux-specific. They need the "usbfs" in the sys tree. Furthermore there is a Tcl shell/interpreter required. And of course all of it depends on "udev".
  With this "framework", ambiguities in device IDs are sorted out, every device will get the right switching configuration, the serial driver is loaded and bound if the device is not yet included in the source code, and a convenience link ("/dev/gsmmodem") is added which points to the correct port. In the ideal case, no user interaction is necessary except plugging in.

Unfortunately, there is no standard way on embedded devices how to handle hot-plug events.

thanks for your advice