Re: cellular modem APIs - take 2

[Denis Kenzior <denkenz@gmail.com>]

Hi Johannes,

> 
> It just seemed that people do want to have a netdev (if only to see that
> their driver loaded and use ethtool to dump the firmware version), and
> then you can reassign it to some actual context later?

I can see that this is useful for developers, but really 
counterproductive in production.  You have a bunch of services (systemd, 
NM, ConnMan, dhcpcd, etc, etc, etc) all observing the newly created 
devices and trying to 'own' them.  Which makes no freaking sense to do 
until those devices are really usable.  Just because it is a netdev, 
doesn't mean it is ethernet or behaves like it.

That also leads to expectations from users that want stuff like 
udev-consistent-naming to work, even though udev has no idea wtf a given 
device is, when it is ready or not ready, etc.  And the flip side, there 
may be systems that do not use systemd/udevd, so the daemons responsible 
for management of such devices cannot sanely assume anything.  It is 
just pure chaos.

And then there's hotplug/unplug to worry about ;)

So I would like to reiterate Marcel's point: creating unmanaged devices 
should not be the default behavior.

> 
> It doesn't really matter much. If you have a control channel and higher-
> level abstraction (wwan device) then having the netdev is probably more
> of a nuisance and mostly irrelevant, just might be useful for legacy
> reasons.

Which we should be trying to eradicate, not encourage ;)

>> Should you really need to account for these specially, or would some
>> kind of sysfs linkage like SET_NETDEV_DEV() be more appropriate?
>>
>> Really all you want to do is (a) identify which WWAN device a given
>> control/data channel is for and (b) perhaps tag different control/data
>> channels with attributes like primary/secondary/gps/sim/etc often
>> through USB attributes or hardcoded data on SoCs.

Userspace can also choose to do its own multiplexing, so you can't even 
really assume the above is what you 'want'.

Regards,
-Denis