On Wed, 2009-07-22 at 14:07 +0300, Rémi Denis-Courmont wrote:

On Wednesday 22 July 2009 12:15:34 ext Marcel Holtmann wrote:

quoted

Hi Alan,

quoted

quoted

The AT stuff is really problematic. Look at the hoops ISDN and software
modem drivers go through to emulate AT commands. I know even of a
CDC-ACM modem which can't deal with AT commands inline (that's within
spec). It seems to me we should have a modem API in kernel.

For devices which don't deal in AT commands probably but for devices
whose firmware provides an AT command interface over serial I would
disagree.

I fully agree here. Even if you think you get AT commands under control,
you really won't in the end. That standard is so wildly mis-interpreted
that it is not even funny anymore.

Possibly. Does anyone known of any "species" bypassing AT commands entirely, 
other than Phonet? as far as GPRS is concerned?

There are any number of devices that expose only one AT port (which of
course gets used by PPP for data) and then a proprietary port.  The
proprietary port usually uses a custom USB protocol that can also handle
SMS, status, RSSI, etc while the AT/PPP port is being used by ppp.

So if that's the case for phonet, maybe you just want to provide either
(a) documentation of the setup/status/sms/etc protocols, or (b) a shim
library implementation for them that handles communication with the
device itself.

But IMHO, the call setup stuff is probably better done from userspace.
It's a really hard API to abstract.  I guess you could write a netlink
API for it like we have for 802.11, but with GSM/CDMA the standards are
so widely ignored that it's just going to be impossible to get a stable
kernel API for anything like this.  The actual logic and higher-level
stuff has gotta be in userspace, while the low-level communication
channel bits (serial, USB, phonet, etc) should live in the kernel.

Dan