idea for a (potentially) more viable approach than blacklisting ad hoc

[Sven Köhler]

Hi Lars,

Am 01.04.2014 11:34, schrieb Lars Knudsen:
> Hi guys,
>
> After looking at how usb serial devices attach and are treated on linux,
> windows (not really working at all ;)) and mac, I have an idea that
> *could* cater for both modems and non modem cdc devices (disregarding
> mal formed USB descriptors, etc.):
>
> We could let any CDC device mount as the /dev/ttyACMx (or /ttyCDCx)
> *and* have a /dev/ttyMODEMx device created at the same time that the
> modemmanager can have full control over - but at a lower priority than
> /dev/ttyCDCx - so that any attempt to connect with ttyCDCx would cut off
> ttyMODEMx while noting is communicating directly with ttyMODEMx

This seems to impact the kernel driver. The driver would have to provide 
both ttyCDCx and ttyMODEMx and detach the latter from the device when 
the former is opened. I assume the following answer would be given by 
the kernel developers: This is a user-space issue, that is to be solved 
in userspace (say, via dbus).

Furthermore, the kernel would detach ttyMODEMx at any point - say, in 
the middle of sending an AT command. In other words: the communication 
over ttyMODEMx would stop at an arbitrary point and the program opening 
ttyCDCx would have to somehow manage to resume or reset the 
communication somehow.

> One could consider different variants of this approach - and even look
> at how apple does it, where 2 devices seem to appear (one for modem and
> one for data connection that we use) when we plug in our usb serial device.

So what does it work like on OSX? Do the devices really work as you 
describe above? Or is the one simply an alias for the other?

> (Please be kind if this has been proposed earlier ;))
>
> thoughts?

What you propose doesn't really work for devices that get confused by 
being probed with AT commands. I don't remember for example, what the 
SAM-BA in system programmer would do in response to AT commands. It is 
currently black listed, but let's assume it wasn't. In the worst case, 
half an AT command would have been send, and after opening I would have 
to send a terminator (newline), then guess whether I would expect a 
reply or not, and then send some proper commands. I don't like the part 
where a program has to guess (because it can't) and I despise timing 
based approaches (like read timeouts).


Regards,
   Sven