DSS usage

[Dmytro Milinevskyy]

----- Original Message -----
> Dmytro Milinevskyy <dmilinevskyy at sequans.com> writes:
> 
> > Hello Bjørn,
> >
> > ----- Original Message -----
> >> Bjørn Mork <bjorn at mork.no> writes:
> >> > Dmytro Milinevskyy <dmilinevskyy at sequans.com> writes:
> >> >
> >> >> 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.
> >
> > This approach still requires the network interface to be always
> > "UP".
> 
> Yes, that does not change with this.
> 
> I do plan on adding the "IP Session 0 VLAN" to the API, which I
> believe
> makes the restriction much easier to live with. The master must still
> alwasy be up to allow any DSS or IP session, but you can then avoid
> having any IP management application like dhclient or NM or whatever
> touch the master netdev.  It can be dedicated to the MBIM management
> application (like for example libmbim).
> 
> This also has the additional advantage of decoupling the MBIM
> wMaxSegmentSize from the IP session 0 MTU, which I believe is
> necessary
> also for some IP session use cases. As it is today, it's impossible
> to
> configure a higher MTU on any IP session > 0 than the MTU on IP
> session
> 0.
> 
> And with the fix for unaccelerated VLAN tagging this again makes it
> possible to send IP session 0 frames without an additional penalty.
> Hmm, thinking of it now that might still be possible.  I'll rework
> the
> proposed bugfix. So forget this last point.
> 
> 
> > Will it be managed by libmbim?
> 
> That sounds like a reasonable way to do it, but it's really up to the
> userspace implementation.  There will be more than one way to arrange
> this, and I'm not sure there is one "correct" way which suits all.
> 

That said nobody is interested in my patches for kernel-space driver?

thanks,
~ dmytro

> 
> 
> Bjørn
> 


-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.