Hello,
Ubuntu community is attempting to fire off some discussion whether or not to include usb-modeswitch in next ubuntu release. The motivation is clear: to improve the out-of-the-box experience with 3G modems.
Timo Jyrinki has a nicesummary of the discussion so far.
It seems that there are three players at the moment; usb-modeswitch, udev and the kernel. Each are preparing their own solutions for the same problem and for me it seems that the udev effort is completely overlapping with usb-modeswitch.
I would like to hear input from usb-modeswitch community and developers on these matters. I'm not that familiar with usb-modeswitch and it's development, but I really would like to see discussion and co-operation between different parties.
- Is usb-modeswitch suitable to be included in next ubuntu release?
- Is usb-modeswitch effort overlapping with udev effort (modem-modeswitch)?
- Is there any change usb-modeswitch and udev developers could join their efforts to get better 3G support for everyone?
- And how is the kernel fitting in this picture?
-
kaijanmaki
- Posts: 1
- Joined: 15 Feb 2010, 11:57
Hi kaijanmaki,
I join this conversation as part of the "usb-modeswitch community". I also reached this place because my distribution was unable to make my modem work out-of-the-box. Find my own cents below:
Kernel DTRT
I am one of those who expect kernel to do the right thing. However, I am also one of those who don't like kernel doing things on its own (without me triggering things somehow). Operating system should enable user to do everything and not just take the "usual path". Lets examine two examples:
- Current consolidation trend pushes administrators into utilizing virtualization. Noone would want its host platform limiting guests or not letting guest systems really handle their passed-through hardware on their own.
- Operator/Manufacturer "X" wants to go the "Linux" path and invests money and effort into supplying a GPL Linux equivalent of its "usual-software-which-displays-its-logo", through that ZeroCD volume. What a pitty, that volume is inaccessible because kernel thought about switching Device already.
- Customer "X" wants to read "Manual" or "Warrantly limitations" or "Working conditions" of its device. This document resides on ZeroCD volume. Volume is unreachable. User is limited.
We've witnessed before builds/distributions which forced user to blacklist usb_storage driver for them to be able to work the way they wanted to. As a user, I do not want to reach a point that I will be blacklisting things just because "default" attitude does not fit my setup. Spreading hardware-specific support-logic across multiple components (scsi, usb_storage, option, usbserial) will produce workflows hard to maintain and debug. During current times, that we even "try" to switch to FUSE, I think is best to just leave kernel alone. Forcing a user to upgrade/recompile kernel because happens to have a newly appeared Device is bad practice which, usually, has the potential to also drive user away from distribution-supplied kernel images. If I was put a gun on my head to implement something on kernel-space, I would only offer a new special IOCTL and nothing more.
Udev or usb-modeswitch?
This kind of question is actually misleading or inaccurate or improperly set. Both modem-modeswitch and usb-modeswitch offer udev rules that make sure action is taken upon device plug. They both rely on same hooking mechanism (udev add action) for kicking in and they both need to be run with root privileges from userspace. To the end-user, the program that actually takes care switching the device, does not really matters, as long as it works. I wouldn't personally care even if it had been a service available to file manager over DBUS. However, those are my notes:
- A DBUS offered solution is not applicable to systems with no graphical environment.
- Usb-ModeSwitch configuration files, while reduntant in information (replicating same strings over and over), provide an amazing flexibility both in supporting newer devices by just importing a new file, and never ending filtering capabilities by distringuishing devices that come with the same "initial" USB IDs (see 05c6:1000 and 19d2:2000). If it is indeed considered a problem, they can easily be converted, altogether, into a single "getent-parsable" file.
- You may have noticed already that I've been using device instead of modem. ZeroCD, as its name implies, is a solution which allows manufacturers to ship devices without an optical media containing required software. While initially adapted by 3G modems, we should expect it to be spread among other device classes also. Within Usb-ModeSwitch device database, one can discover digital photoframes and WiFi adapters already using ZeroCD. Modem-modeswitch definately needs its name to be changed.
Sounds like I am not answering. Well, as a user, I do not care, as long as it really "works" and allows me to make it "not-work" if I want to. No matter what you choose, you should make sure is good enough. Or else, you do not really help project you choose, instead you are giving it a bad name. As an example, many users switched to wicd due to bad NM functionality in karmic. As long as distributions ship broken things, people work around default setup. So, my answer is: Either make modem-modeswitch work as good as usb-modeswitch, or be doomed to Usb-ModeSwitch, and whatever else might appear, helping disappointed users. If you choose to go the Usb-ModeSwitch way, for god sake, please, do not ship a badly integrated/tested or outdated version, or you will not be really helping users or project itself.
As Sakis, I prefer helping my system, find its way supporting a new device, by just adding a new file within /etc/<whatever name here>/ rather than rebuilding.
Sakis
I join this conversation as part of the "usb-modeswitch community". I also reached this place because my distribution was unable to make my modem work out-of-the-box. Find my own cents below:
Kernel DTRT
I am one of those who expect kernel to do the right thing. However, I am also one of those who don't like kernel doing things on its own (without me triggering things somehow). Operating system should enable user to do everything and not just take the "usual path". Lets examine two examples:
- Current consolidation trend pushes administrators into utilizing virtualization. Noone would want its host platform limiting guests or not letting guest systems really handle their passed-through hardware on their own.
- Operator/Manufacturer "X" wants to go the "Linux" path and invests money and effort into supplying a GPL Linux equivalent of its "usual-software-which-displays-its-logo", through that ZeroCD volume. What a pitty, that volume is inaccessible because kernel thought about switching Device already.
- Customer "X" wants to read "Manual" or "Warrantly limitations" or "Working conditions" of its device. This document resides on ZeroCD volume. Volume is unreachable. User is limited.
We've witnessed before builds/distributions which forced user to blacklist usb_storage driver for them to be able to work the way they wanted to. As a user, I do not want to reach a point that I will be blacklisting things just because "default" attitude does not fit my setup. Spreading hardware-specific support-logic across multiple components (scsi, usb_storage, option, usbserial) will produce workflows hard to maintain and debug. During current times, that we even "try" to switch to FUSE, I think is best to just leave kernel alone. Forcing a user to upgrade/recompile kernel because happens to have a newly appeared Device is bad practice which, usually, has the potential to also drive user away from distribution-supplied kernel images. If I was put a gun on my head to implement something on kernel-space, I would only offer a new special IOCTL and nothing more.
Udev or usb-modeswitch?
This kind of question is actually misleading or inaccurate or improperly set. Both modem-modeswitch and usb-modeswitch offer udev rules that make sure action is taken upon device plug. They both rely on same hooking mechanism (udev add action) for kicking in and they both need to be run with root privileges from userspace. To the end-user, the program that actually takes care switching the device, does not really matters, as long as it works. I wouldn't personally care even if it had been a service available to file manager over DBUS. However, those are my notes:
- A DBUS offered solution is not applicable to systems with no graphical environment.
- Usb-ModeSwitch configuration files, while reduntant in information (replicating same strings over and over), provide an amazing flexibility both in supporting newer devices by just importing a new file, and never ending filtering capabilities by distringuishing devices that come with the same "initial" USB IDs (see 05c6:1000 and 19d2:2000). If it is indeed considered a problem, they can easily be converted, altogether, into a single "getent-parsable" file.
- You may have noticed already that I've been using device instead of modem. ZeroCD, as its name implies, is a solution which allows manufacturers to ship devices without an optical media containing required software. While initially adapted by 3G modems, we should expect it to be spread among other device classes also. Within Usb-ModeSwitch device database, one can discover digital photoframes and WiFi adapters already using ZeroCD. Modem-modeswitch definately needs its name to be changed.
Sounds like I am not answering. Well, as a user, I do not care, as long as it really "works" and allows me to make it "not-work" if I want to. No matter what you choose, you should make sure is good enough. Or else, you do not really help project you choose, instead you are giving it a bad name. As an example, many users switched to wicd due to bad NM functionality in karmic. As long as distributions ship broken things, people work around default setup. So, my answer is: Either make modem-modeswitch work as good as usb-modeswitch, or be doomed to Usb-ModeSwitch, and whatever else might appear, helping disappointed users. If you choose to go the Usb-ModeSwitch way, for god sake, please, do not ship a badly integrated/tested or outdated version, or you will not be really helping users or project itself.
As Sakis, I prefer helping my system, find its way supporting a new device, by just adding a new file within /etc/<whatever name here>/ rather than rebuilding.
Sakis
Hi, Ubuntu users!
I could answer on the Losca Blog too if you want. But I'll start on my own turf if you don't mind.
I was hoping for this discussion to take off at some point. The support work I'm doing in this very forum is often tedious and time-consuming, and it's mostly about configuration problems which could - and should - be solved on distribution level instead of fiddling around with individual setups.
That's why I did a tiny bit of advertising for usb_modeswitch recently - mostly in bug reports. It's not narcicissm, it's longing for more couch potatoing
To the facts (and beyond, maybe) ...
The Kernel
Currently, there are switching routines in the kernel for few modems: older Huaweis, older Options and the Sierra range. The current policy of the developers is: if something like switching or firmware loading can be done in userspace, it is not admitted to the kernel code. They would indeed like to throw out all switching code once a viable userspace procedure is established.
See for instance this discussion on the LKML; Matthew Dharm is the maintainer for "usb-storage" which is a likely candidate for including switching code.
Modem-modeswitch
This was an attempt of Redhat's Dan Williams to make switching usable in distributions. At the time, quite a bit of file editing was necessary to run usb_modeswitch properly. The single user was happy to make his/her device work, but obviously this was far from being useful on distribution level.
But, as I can confirm, being up-to-date with new devices all the time is a time-consuming job. So Dan William's recent statements point to a retract of modem-modeswitch.
See the statements here and here.
Unfortunately, the wrong rules are still part of Debian/Ubuntu and are one issue of interference with usb_modeswitch. And I did propose the replacement of modem-modeswitch in a bug report here.
The New USB_ModeSwitch Wrapper
Two reasons to use a wrapper script from the UDEV rules:
I don't have any fixation about the configuration mechanism of usb_modeswitch. The current setup is certainly just one possibility of many. I chose it for simplicity and ease of expanding. I see it the way Sakis put it: add a new config file and a rule for your device and it works (in an ideal world, that is).
There are redundancies in the config files, no question about that. One way to avoid them is to add named parameters as modem-modeswitch does it - without obstructing the option to give raw bulk messages as parameters. I think I can do this without breaking compatibility with existing setups (>=1.1.0).
State of Distributability (what a word ...)
Version 1.1.0 has had a good response so far, which means: very few error reports. Testing was done by Sakis, Glasen (see his blog here) and the Debian package maintainer Didier Raboud. No new bug reports for the "unstable" package 1.1.0-2 (see the Debian page).
Of course, more testing would have to be done, with any former matching rules disabled.
I could answer on the Losca Blog too if you want. But I'll start on my own turf if you don't mind.
I was hoping for this discussion to take off at some point. The support work I'm doing in this very forum is often tedious and time-consuming, and it's mostly about configuration problems which could - and should - be solved on distribution level instead of fiddling around with individual setups.
That's why I did a tiny bit of advertising for usb_modeswitch recently - mostly in bug reports. It's not narcicissm, it's longing for more couch potatoing
To the facts (and beyond, maybe) ...
The Kernel
Currently, there are switching routines in the kernel for few modems: older Huaweis, older Options and the Sierra range. The current policy of the developers is: if something like switching or firmware loading can be done in userspace, it is not admitted to the kernel code. They would indeed like to throw out all switching code once a viable userspace procedure is established.
See for instance this discussion on the LKML; Matthew Dharm is the maintainer for "usb-storage" which is a likely candidate for including switching code.
Modem-modeswitch
This was an attempt of Redhat's Dan Williams to make switching usable in distributions. At the time, quite a bit of file editing was necessary to run usb_modeswitch properly. The single user was happy to make his/her device work, but obviously this was far from being useful on distribution level.
But, as I can confirm, being up-to-date with new devices all the time is a time-consuming job. So Dan William's recent statements point to a retract of modem-modeswitch.
See the statements here and here.
Unfortunately, the wrong rules are still part of Debian/Ubuntu and are one issue of interference with usb_modeswitch. And I did propose the replacement of modem-modeswitch in a bug report here.
The New USB_ModeSwitch Wrapper
Two reasons to use a wrapper script from the UDEV rules:
- Identification:
Some USB IDs are ambiguous; they are found in many devices, probably depending on the chipset used.
To assign the correct switching method (or even to leave them alone), identification via USB ID is just not enough. The script takes care of that.
Technically, this would have been possible with fine grained UDEV rules as well, but they'd grow into something unpleasant and overflowing. O.K., my guts are speaking here. But there is still reason 2 ... - Driver Binding:
Most devices can use the "option" driver after switching. But with new devices popping up quite often, it's a long wait until their IDs are incorporated into the module for automatic recognition.
There is the second way to tell the driver about the new ID via the "new_id" facility, but somebody has to do it. The script is the ideal place for that; it checks for a successful switch anyway.
I don't have any fixation about the configuration mechanism of usb_modeswitch. The current setup is certainly just one possibility of many. I chose it for simplicity and ease of expanding. I see it the way Sakis put it: add a new config file and a rule for your device and it works (in an ideal world, that is).
There are redundancies in the config files, no question about that. One way to avoid them is to add named parameters as modem-modeswitch does it - without obstructing the option to give raw bulk messages as parameters. I think I can do this without breaking compatibility with existing setups (>=1.1.0).
State of Distributability (what a word ...)
Version 1.1.0 has had a good response so far, which means: very few error reports. Testing was done by Sakis, Glasen (see his blog here) and the Debian package maintainer Didier Raboud. No new bug reports for the "unstable" package 1.1.0-2 (see the Debian page).
Of course, more testing would have to be done, with any former matching rules disabled.
Hi there. During my blog post time, I wasn't aware yet of the modem_modeswitch. Anyway, I'm merely an user of Ubuntu, having no developer status there (although I'm a Debian Developer). Therefore the attention and convincing should be achieved towards a Ubuntu core developer who could have a say in it. Possibly the Kernel and Foundations Team as a whole since this affects so many things.
The problem here is that we are already past feature freeze. It's not uncommon to have feature exception granted if one is quick, but the feature exception should be crafted probably by someone here. Then maybe some discussion about it on #ubuntu-devel IRC channel and at the same time a reply to my usb-modeswitch thread on the ubuntu-devel-discuss about the feature freeze request created.
In case the current modem_modeswitch indeed does more harm than it helps, it should probably be included in the same discussion/request to remove it from udev. And furthermore in the same request it's worthwhile to mention that usb-modeswitch and usb-modeswitch-data will need main inclusion request (MIR) as well, if the feature (include usb-modeswitch in default installation) would be implemented. It's simply part of the process needed.
My understanding of the claimed (past) problems and the whole kernel/udev/modeswitch issue is not enough to really drive this forward, but if you think usb-modeswitch should be more beneficial / ease work from Canonical point of view for their 5 year support of the 10.04 LTS and its millions of users than updating kernel quirks for example by backporting those quirk files, then I think this wouldn't be impossible. The main thing they are interested in is that it breaks nothing and it's more supportable than the other options. Another thing is that someone makes it easy and understandable to them that there are no risks or the risks are very low and there is a committed upstream that is willing to help. References on how modem_modeswitch should be removed (simply not installing the binary? is anyone else doing it alreadY?) could be helpful as well.
The problem here is that we are already past feature freeze. It's not uncommon to have feature exception granted if one is quick, but the feature exception should be crafted probably by someone here. Then maybe some discussion about it on #ubuntu-devel IRC channel and at the same time a reply to my usb-modeswitch thread on the ubuntu-devel-discuss about the feature freeze request created.
In case the current modem_modeswitch indeed does more harm than it helps, it should probably be included in the same discussion/request to remove it from udev. And furthermore in the same request it's worthwhile to mention that usb-modeswitch and usb-modeswitch-data will need main inclusion request (MIR) as well, if the feature (include usb-modeswitch in default installation) would be implemented. It's simply part of the process needed.
My understanding of the claimed (past) problems and the whole kernel/udev/modeswitch issue is not enough to really drive this forward, but if you think usb-modeswitch should be more beneficial / ease work from Canonical point of view for their 5 year support of the 10.04 LTS and its millions of users than updating kernel quirks for example by backporting those quirk files, then I think this wouldn't be impossible. The main thing they are interested in is that it breaks nothing and it's more supportable than the other options. Another thing is that someone makes it easy and understandable to them that there are no risks or the risks are very low and there is a committed upstream that is willing to help. References on how modem_modeswitch should be removed (simply not installing the binary? is anyone else doing it alreadY?) could be helpful as well.
Unfortunately, I'm one day away from a vacation, so I am not able to initiate anything much for some weeks.
I'm still wondering why there is no response regarding the "Vertex 100" bug that I mentioned above (Bug 500276). Is the problem really so hard to understand?
Well, it looks like we have to wait until fall ...
I'm still wondering why there is no response regarding the "Vertex 100" bug that I mentioned above (Bug 500276). Is the problem really so hard to understand?
Well, it looks like we have to wait until fall ...
There was now a relevant comment on ubuntu-devel-discuss by Scott James Remnant, suggesting that the "competition" between kernel, modem-modeswitch and usb-modeswitch should be had at the linux-hotplug mailing list, so that the result would be agreed by all relevant parties.
See https://lists.ubuntu.com/archives/ubunt ... 10717.html and the followups.
At the same time, the usual answer is that there are tens of thousands of open bugs in Launchpad, and only a handful of paid workers at Canonical. Even with the assistance of community, the bug reports generally don't have the manpower. Therefore it's more likely something will be done if eg. patch is readied for all aspects of the problem and even PPA packages made available for testing. Even after such things it may require communicating via mailing lists, IRC or direct e-mail with the person of core team most involved in the subject (in this case probably Scott with the udev experience). And most of all, there has to be a kind of clear upstream acceptance of what's the way forward.
I've battled my way through some of problems I've had interest in, and it's simply a combination of communicating in a right way with the right parties and making the bug fixing as easy as possible to those with upload right, both from technical and "social" (acceptability) aspects.
Anyway, if Scott is right and the correct upstream place to deal with the issue is linux-hotplug mailing list, that would be the place to address the issue. Peteris Krisjanis already proposed to possibly bring up the issue there, although it seems he thinks he doesn't have the authority without backup.
See https://lists.ubuntu.com/archives/ubunt ... 10717.html and the followups.
Well, as it involves a "non-supported, community" package, ie. universe package usb-modeswitch, it's a larger issue than the package the bug is filed against, udev. It's something that won't be decided in one bug report.Josh wrote:I'm still wondering why there is no response regarding the "Vertex 100" bug that I mentioned above (Bug 500276). Is the problem really so hard to understand?
At the same time, the usual answer is that there are tens of thousands of open bugs in Launchpad, and only a handful of paid workers at Canonical. Even with the assistance of community, the bug reports generally don't have the manpower. Therefore it's more likely something will be done if eg. patch is readied for all aspects of the problem and even PPA packages made available for testing. Even after such things it may require communicating via mailing lists, IRC or direct e-mail with the person of core team most involved in the subject (in this case probably Scott with the udev experience). And most of all, there has to be a kind of clear upstream acceptance of what's the way forward.
I've battled my way through some of problems I've had interest in, and it's simply a combination of communicating in a right way with the right parties and making the bug fixing as easy as possible to those with upload right, both from technical and "social" (acceptability) aspects.
Anyway, if Scott is right and the correct upstream place to deal with the issue is linux-hotplug mailing list, that would be the place to address the issue. Peteris Krisjanis already proposed to possibly bring up the issue there, although it seems he thinks he doesn't have the authority without backup.