DSS usage

[Bjørn Mork]

Dmytro Milinevskyy <dmilinevskyy at sequans.com> writes:

> I tend to agree that DSS data should not be forwarded via VLAN
> interfaces as it's not a natural approach for such data pipes.

The VLAN is a generic interface for you to further refine.  It is not
intended as a final stop for DSS pipes.

I understand that you have a specific DSS application in mind where a
character device would be fine, and I guess that is going to be the most
common case.  But I have no problems imagining applications where the
character device would only be the first stop.  Including applications
where keeping the framing is an advantage.

I also see a number of cases where I like the idea of being able to
snoop on a specific DSS channel.

> Also userspace has to deal with bogus MAC address inserted by mbim
> driver.

Actually userspace has to add and strip full ethernet headers.  The
content doesn't matter, though.  Yes, I admit it is weird.  But this
interface isn't intended to be used for anything but specific MBIM DSS
userspace tools.  And they have to be aware of whatever DSS data
interface implementation we've chosen in any case. 

> Of course as the long term solution a DSS channel should be visible as
> a character device.

A network device can easily be converted to a character device in
userspace using a pty. socat is one userspace implementation.  There is
nothing preventing the implementation of a similar proxying solution in
software written for some specific DSS application.

In any case, I see no reason to reimplement this proxying functionality
as a kernel driver, having to add a driver specific API to manage the
character devices.  The data manipulation would maybe be simpler, but
the device management API most certainly would not.

It's not like we can make the driver just create a character device and
make it immediately available for any legacy application written for a
serial port. MBIM DSS sessions are not just "there", like for example a
USB serial function. Something has to manage the session, and this
something should know what type of data the stream contains.  This
"something" can then just as well set up the necessary data
transformation for any legacy application it wants to support.

For example, if you want to support NMEA over DSS using gpsd, then you
will create a userspace application which
 - starts the appropriate DSS session
 - creates the matching VLAN
 - proxies the VLAN to a pty, adding and stripping ethernet headers
 - adds the pty to the list of gpsd devices

I believe it would make sense for libmbim to provide utility functions
taking care of the first three.


Bjørn