DSS usage

[Dmytro Milinevskyy]

----- Original Message -----
> Dmytro Milinevskyy <dmilinevskyy at sequans.com> writes:
> 
> > Hi Bjørn,
> >
> > I've already started to work on a concept of DSS through char dev.
> > In the attachment you can find the first trial.
> > It's not extremely stable version but I can exchange data between
> > the host and the device
> > even if the main wwan interface is down. The DSS channel is
> > registered as a misc device.
> >
> > There are several points which so far I don't know how to implement
> > correctly:
> > 1. how to publish/delete new DSS channel? Via ioctl for cdc-wdmXX
> > device or via NL msg. Honestly I would prefer to use NL.
> > 2. what is the best way to destroy DSS channels if MBIM device goes
> > offline(i.e. it's being unbound).
> >    I'm afraid that I can't sleep in this context to wait for all
> >    DSS users to finish with the cleanup
> > 3. there's a limitation on the number of misc devices in the system
> > since it uses same major index.
> >    Don't know whether it's a big limitation though.
> >
> > The attached patches are just for the review, don't try them at
> > home ;).
> 
> Ah, nice. You have been active :-)
> 
> I must say that this looks a lot better than my earlier experiments.
> 
> BUT...  It's a lot of code, and it will be much more when finished.
>  And
> most of it is really just reimplementing a task which is done
> perfectly
> well in userspace today.  Regarding the DSS publish/delete, I agree:
> either ioctl or NL, and preferably NL.  But you are just replacing
> one
> odd userspace API with another.  The DSS tools will sill have to be
> very
> aware of the kernel API exported by the MBIM driver.
> 
> In short: I don't think moving the vlan => tty conversion into the
> kernel is going to be an improvement. If it can be done in userspace,
> then do it in userspace.
> 
> The ability for usbnet to receive data when the interface is down is
> interesting. That is certainly useful.  But it has a major downside:
> You loose the ability to stop reception.  Maybe this can be fixed? If
> there are no IP sessions and no DSS sessions, then you really do not
> want usbnet running.
> 
> This code is also going to be sold in to the usbnet maintainers.  I
> suggest getting some comments from Oliver Neukum before putting too
> much
> work into it.
> 
> I hope I am not coming out too negative here.  If you can make this
> fly,
> then I have no real objections.  But I think there is a lot of work
> remaining and I'm just not sure it's worth it.

Thanks Bjørn for the feedback,

There are several reasons to move to char dev:
1. uniform API for device app: no need to treat different types of DSS connection(no vlans on WinOS for example)
2. vlan does not suite very well for all the applications.
   For example it's not possible export device's serial console via vlan. 
   I know that I can connect via telnet and do all the job but I can't use it as a real debug console.
   (I admit that DSS is a backdoor for MBIM device vendors)
3. avoid all the limitations introduced by vlan: MTU, link status, eth header, bogus traffic generated by userspace and kernel(network discovery traffic).

It's crystal clear that I have to do my best to sell it to you and USB maintainers.
And I also hope this worth the time and effort.

~ 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.