[lkundrak]

In the better case it's empty and useless, in worst case it's something very irrelevant (a bus name of a random parent of a device that happens to have one, such as the usb controller) and harmful -- when passed to the dispatcher it appends it to the sysfs path, making it invalid.

To add insult to injury, the / is escaped as _ for systemd (as opposed to the correct "\x2d"), so the dispatcher gets even more confused.

Both of these issues exhibit on Odriod C2, with DWC2 platform USB controlers, that happen to have device-tree names of "dwc2_a" and "dwc2_b". Udev uses that for %b of the modem device:

When the actual device path is /sys/devices/platform/dwc2_b/usb1/1-1/1-1.4/1-1.4:1.0 (and a link in /sys/bus/usb/devices/1-1.4:1.0), udev helper starts the service with dwc2_b_1-1.4:1.0 argument, which the dispatcher translates to /sys/bus/usb/devices/dwc2/b. /sys/bus/usb/devices/dwc2_b/1-1.4:1.0 would still be incorrect.

Let's just lay it to rest.

[lkundrak]

Whoops, the patch was wrong, since it's the usb_modeswitch-data that passes the %b argument.
Updated the patch to keep the compatibility.

This is not too nice though.

Ideally, the data package should tag the device for the modeswitch with

Code: Select all

TAG+="usb_modeswitch"

rule and then the usb_modeswitch package should ship a rule that does

Code: Select all

TAG=="usb_modeswitch", SYSTEMD_WANTS+="usb_modeswitch@%k"

without the shell script and involved overhead (including the format of command line parameters).

[Josh]

I was actually thinking along the same lines myself regarding the busname. There is some redundancy involved from a time when udev was not very consistent yet between versions.

Regarding the 'ideal' solution, I'm not sure about dropping 'upstart' and old systems support though. Also, the shell script provides a facility to symlink the serial modem ports to use for the actual PPP connection (again, a provision from a time when systems didn't know what to do with all those serial USB ports of a 3G modem).

I know that Network and modem manager nowadays handle practically all classic USB modems correctly. The question is: are there any important long-running distributions that may be disrupted by changes like these?