On Mon, 2019-04-15 at 12:29 +0200, Bjørn Mork wrote:
>
> I don't understand where you are going here? Neither QMI, AT command nor
> MBIM management are transported over netdevs. AT is usually transported
> using simple USB bulk streams, exported to userspace as tty devices by
> some USB serial driver. Both QMI and MBIM management are transported as
> USB control messages, and exported to userspace as chardevs. There are
> no netdevs involved.
OK. I've also been looking at a driver for Intel modems, and I think it
works that way.
> > and people do things like "socat" to set up
> > PTYs and pretend to have serial channels there, on top of the netdevs?
>
> I assume you are referring to my MBIM DSS examples here.
I was more thinking of what I've been told the Intel modem does,
actually. But that in turn might very well be inspired by what you
documented there. I think the folks doing this were just trying to make
it work and nobody really understands the whole landscape.
> I don't know
> if anyone is actually using that, so you should probably ignore it...
> I'll happily admit it was a bad idea. Should have just added the
> necessary code to map DSS channels to some sort of character device in
> the driver, like most users requested.
OK. So I guess a framework should consider that possibility, and let you
create new chardevs for a given (DSS) channel?
> But there really isn't anything in the MBIM spec saying how DSS should
> be used. DSS is a generic data stream. Could easily be connected to a
> single TCP session for example, in which case you'd probably want to
> connect it to a TCP session in the other end too. So I wouldn't want to
> force DSS into character devices on the host end.
Fair point.
I suppose some of these may also be debug channels that give you modem
debug information, which is useful (if you can interpret it).
> This doesn't rule out
> a userspace controlled optional mapping though. We could probably still
> add that, replacing the VLAN mapping with a chardev for a specific DSS
> session if requested by userspace. I guess this is something to
> consider for a generic cellular framework - supporting non-ip data
> streams between modem and host.
Right.
> Adding to my previous excuses: The DSS implementation in the cdc_mbim
> driver was added without having seen a single modem firmware with *any*
> type of DSS support. It was purely based on spec{ification,culation}.
> The VLAN mapping, along with examples of how to use socat to further map
> the streams from VLANs into suitable application specific forms, seemed
> like a simple and flexible enough solution.
:-)
johannes
