bjorn at mork.no
Fri May 9 02:08:57 PDT 2014
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3351 bytes
Desc: not available
More information about the libmbim-devel