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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
