[PATCH] Add DEVICE_OPEN_FLAG_DATA_FORMAT

[Dan Williams]

On Fri, 2012-09-07 at 10:50 -0700, Marcel Holtmann wrote:
> Hi Bjorn,
> 
> > >> I am asking because it seems we have to add some data interception hooks
> > >> to cdc_wdm to support MBIM, and I am playing with the idea to let the
> > >> qmi_wwan snoop on "Set Data Format" messages and just support whatever
> > >> mode you set.  It can most certainly be done, and it won't be much code
> > >> either.
> > >
> > > instead of doing some magic snooping, I would prefer that we add some
> > > ioctl that allows us to list supported modes and allow them to change.
> > > So userspace can make the call here. And not the kernel doing some magic
> > > behind the scenes.
> > 
> > I'll save us both some time and just assume that you are correct this
> > time as well :-) Snooping the QMI messages is probably not a good idea.
> > 
> > But I do not think an ioctl is wise either.  Please see
> > http://www.spinics.net/lists/netdev/msg209401.html
> > 
> > I like the way davem leaves no doubt :-)
> 
> actually ioctl are not as bad as some kernel developers try to make them
> out. They are still used and we are adding them for multiple drivers
> every single day. Same goes for sysfs.

The problem with ioctls isn't that they should be done with netlink
instead.  The problem is that they are often the first solution for
problems that have better solutions.  If you add an ioctl, you are often
adding a one-off fix for a specific driver that userspace now has to
accommodate on a one-off basis.  Better to figure out a more generic
solution that doesn't require a private knob, if you can.  Honestly it
would be nice if qmi_wwan could ask the firmware what format it was
using, and then create a wwan0 for 802.3 or some other interface type
that doesn't pretend to be ethernet for RawIP.  And then reconfigure
interfaces if that changed, so userspace would see the standard udev
events for network interfaces added/removed.  Not sure how that gets
accomplished though.

Dan

> Some of the netdev developers that propose netlink for everything are
> also confused btw. ;)
> 
> That said, I am fine with ethtool approach as well. If that API can be
> used for this task, then by all means use an existing one.
> 
> > While testing the features, I used the new ethtool --show-priv-flags/
> > --set-priv-flags.  Such an implemetation may be accepted upstream, and
> > would probably fit your needs as well?  It would use one flag per
> > feature (RawIP, QoS) and allow you to query and set these using the
> > ethtool API.
> 
> Yes, ethtool API seems a good fit. The important point from my side was
> to let userspace drive this.
> 
> > But I still believe adding this at all should be based on need, like
> > some firmware failing in 802.3 mode or someone actually finding a use
> > for the QoS header (and documents its usage!).  I don't think we are
> > there yet.
> 
> Works for me.
> 
> Regards
> 
> Marcel
> 
> 
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel