Re: wwanX vs usbX

[Dan Williams <dcbw redhat com>]

On Tue, 2013-02-26 at 16:52 +0100, Bjørn Mork wrote:
> Marcel Holtmann <marcel holtmann org> writes:
>
> > > Putting naming policy in the kernel like this quite appalling, IMHO.
> > > Having device and vendor specific entries in the cdc_ncm and cdc_ether
> > > class drivers just because we need different kernel device names is
> > > completely unnecessary.
> >
> > that is what we have the DEVTYPE=wwan value in the uevent sysfs entry
> > for. That is the one that needs to have the right value.
>
> Well, OK, but that has exactly the same problem except that there is no
> way to override the type in userspace if the driver gets it wrong.

Yeah, but we hope the driver doesn't get it wrong...

> > > I see the need to detect whether a device needs an external management
> > > channel or not. But this could have been handled much more elegantly by
> > > using the same logic MM applies when collecting all modem ports: If we
> > > find an associated management channel (AT serial port, QMI /dev/cdc-wdmX,
> > > MBIM /dev/cdc-wdmX or whatever), then this channel will manage the
> > > network device regardless of whether the name is usbX, ethX, wwanX or
> > > something else.  If there is no management channel then we can just as
> > > well assume that the device works without management.
> > >
> > > The current scheme is bad for several reasons:
> > > - requires otherwise unnecessary vendor/device specific entries in class
> > >   drivers,
> > > - vendor entries may erronously name non-managed devices as wwanX if the
> > >   same vendor makes both types of devices,
> > > - adding device specific entries will always lag behind compared to
> > >   class entries,
> > > - policies should be set in userspace
> > >
> > > Just my € .02
> >
> > Matching by network interface names is a really bad idea. That is why I
> > added DEVTYPE support for WWAN, Wireless LAN, Bluetooth and WiMAX way
> > back then.
> >
> > You also forget the simple fact that network interfaces can be just
> > renamed. And newer systemd version will do exactly that to achieve some
> > sort of persistent naming.
>
> I may have ignored the fact, but I did not forget it :-)
>
> Anyway, the issues with the DEVTYPE is the same.  There is really no way
> for the driver to know what DEVTYPE to set for e.g a Huawei or Dell CDC
> NCM device.  It sort of works today because we have these weird vendor
> specific entries in some of the class drivers, but that is just waiting
> to fail as soon as one of these vendors start making non-wwan devices...
>
> And it is ugly as hell.

This is true.  It is ugly, and it's a constant battle to tag every new
adapter as DEVTYPE=wwan, and we'll always be behind.  It's the same
thing with udev rules, we'll always be behind.  Plus udev rules are
project specific now, so it would also be ugly to have eg NetworkManager
look at ModemManager-provided udev rules tags so that it knows to ignore
a WWAN device when ModemManager is not running.

On Windows people only install the drivers and software for *one*
device, so this is never a problem.  When they buy a new WWAN device
from the same vendor, the old software gets uninstalled and only the new
drivers exist.

I'm not really sure how to fix it...

Dan