DSS usage

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:
> On Fri, May 9, 2014 at 9:41 AM, Bjørn Mork <bjorn at mork.no> wrote:
>>> 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.
>>
>> If I were more of a programmer, then I would of course have worked on a
>> real implementation for libmbim.  The truth is that I don't have a clue
>> where I would start doing that.  So therefore, this proof-of-concept is
>> all you get for now.
>
>
> Kind of like this approach. So, if I'm not mistaken, a single
> user-space app can take care of providing ptys for the different DSS
> sessions managed in the system, by R/W packets from/to the network
> interface and doing the forwarding to/from the corresponding PTY,
> without any VLAN interfaceinvolved. This can likely be integrated in
> the mbim-proxy setup that Greg wrote, which I still need to review;
> i.e. whenever the mbim-proxy receives a DSS channel creation request,
> it could also transparently create a new pty for it. We could then
> provide an internal API between mbim-proxy and libmbim to report the
> pty path,  or otherwise, let libqmi build itself the path based on the
> DSS channel number or something. Is that the general approach you're
> suggesting? Or did you have some other thing in mind?

That is a very good description of what's on my mind.

I'm attaching my current attempt on fixing the driver.  I tried to make
the patch apply to all currently maintained stable versions, and at
least it did work for v3.10.

Not yet tested....

Still to come is the IP session 0 VLAN, which I have almost decided is a
necessary API addition no matter how Dmytros work goes.  It's just as
much about decoupling IP sessions > 0 from IP session 0.  And with the
attached fix there is also a new penalty for using untagged frames.
Unfortunate, but absolutely required.



Bjørn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-net-cdc_mbim-do-not-drop-unaccelerated-VLAN-tagged-f.patch
Type: text/x-diff
Size: 3351 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140509/2d498837/attachment.patch>