Hi,
Greg KH:
> > Please contact me privately for details.
>
> Oh come on, don't tease us, let's know what could be done here on this
> driver :)
Well, you talked me into it ... here's my current list of interesting
things to do to ^W with the Option driver.
All of the following is of course open to discussion. If somebody has a
good reason for saying that one or more of these enhancement ideas is
bullshit, please don't hesitate to speak up.
* The thing has no flow control whatsoever. Somebody should hammer
their device with data while online and check if it tells us to slow
down somehow. (This is, ideally, a job for somebody with a data
flatrate contract.)
* ... except that it probably doesn't. In that case it might do the
flow control in-band, which could happen either using the venerable
^S/^Q characters, or with flow control messages via multiplex mode.
At the moment the Option driver doesn't know what the hell a ^S
is or why it should care, and unless evidence shows up that it needs
to I'd like to keep things that way.
* Multiplex mode, however, is independently useful. As the name implies,
it is a way to talk to more than one part of a GSM modem concurrently,
so you can do stuff like check the uplink quality (or send text
messages ;-) while online. It is entered with AT+CMUX; you may or
may not be able to leave that mode without physically powering down
the USB bus.
The OpenMoko people have written a kernel driver for multiplexing,
but that is still out-of-tree. I'd like that to get fixed.
* The number and size of the USB buffers which the Option driver uses
are chosen very conservatively, so as not to overwhelm some of the
older cards which it supports. Needless to say, that means that the
driver can't keep up with UMTS data rates.
Its list of device IDs needs to be enhanced (in a blacklist-style sort
of way) so that the driver can pick the limits from there, instead of
having to use some sort of global pessimum.
* ... or from a couple of module parameters, so that people can
test whether their device supports larger limits without recompiling.
* Speaking of module parameters: Resurrecting the vendor=/product= thing
for the Option driver is something that I'm of two minds about. Yes it
means that you can quickly connect new devices, but on the other hand
people for whom that works tend not to send in patches for new device
IDs. Thus, in the long run even more users need to hack their
/etc/modules file for devices which should work out of the box. :-(
* That list should carry some other info -- like, which of the three
endpoints that some of these devices export (see the current driver
for the mess *that* is) is the actual data port and which is the side
channel (or, when multiplexing, which channel corresponds to these --
ETSI conveniently forgot to standardize that).
* Speaking of sysfs, it'd be nice to export some more details so that
userspace doesn't need to duplicate our long list of device IDs,
or magically know what kind of device the Option driver controls,
to understand that this strange new device that's just been plugged in
is a GSM modem.
* There's at least one other driver which has been cloned from option.c
in the kernel, as well as at least one which is still based on the
"standard" usbserial but shouldn't be. It'd make sense to (re-)unify
these.
* Some of these GSM modems are connected by way of a PC-Card with an
OHCI USB adapter. Needless to say, if you pull the card at the exact
wrong time, Bad Things might happen. The kernel's USB stack has
gotten a lot better about not being stupid (like panicing, or leaving
locks locked) but it's not perfect yet.
So somebody should do a pull-the-card test and then track down any
stupid things that happen.
This is a job for anybody who does *not* have any other USB devices
connected to the computer s/he uses for such tests; USB debugging
kindof sucks when you get a couple of kernel messages per keystroke
and/or disk access ...
All in all, enough things to do to more than overwhelm the two people
who already emailed me and expressed their interest. ;-)
The end result I'd like to see is that, when the user plugs in their GSM
modem, that fact gets propagated via udev/hal/dbus so that a GUI window
pops up and asks for the PIN, after which (a) Network Manager sees the
device and is able to connect, and/or (b) I can use Telepathy to send
and receive text messages. (Using the card as a phone should of course
also be possible, but some of those modems don't even support audio
data...)
Much of that is user space, of course, but the kernel needs to provide
the infrastructure to make it happen.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf at smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
To love another is not enough....It is not enough to be "supportive" and
"there for them," and all the rest....She is waiting for the signal of
deep feeling, that one tear that says, "I admit the wound." -- Clarissa
Pinkola Estes, Women Who Run With the Wolves
