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
