Re: [PATCH] USB host CDC Phonet network interface driver

[Dan Williams <dcbw@redhat.com>]

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:
> > Hi Alan,
> >
> > > > 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