Hi all,
I've been looking at modem drivers, to see what the APIs are to interact
with them, and while I originally thought I had the story sorted out ...
not at all.
Here's the current things we seem to be doing:
(1) Channels are created/encoded as VLANs (cdc_mbim)
This is ... strange at best, it requires creating fake ethernet
headers on the frames, just to be able to have a VLAN tag. If you
could rely on VLAN acceleration it wouldn't be _so_ bad, but of
course you can't, so you have to detect an in-band VLAN tag and
decode/remove it, before taking the VLAN ID into the virtual
channel number.
Creating channels is hooked on VLAN operations, which is about the
only thing that makes sense here?
(2) Channels are created using sysfs (qmi_wwan)
This feels almost worse - channels are created using sysfs and
just *bam* new netdev shows up, no networking APIs are used to
create them at all, and I suppose you can't even query the channel
ID for each netdev if you rename them or so. Actually, maybe you
can in sysfs, not sure I understand the code fully.
(3) Channels are created using a new link type (rmnet)
To me this sort of feels the most natural, but this particular
implementation has at least two issues:
(a) The implementation is basically driver-specific now, the link
type is called 'rmnet' etc.
(b) The bridge enslave thing there is awful.
It seems to me that there really is space here for some common
framework, probably modelled on rmnet - that seems the most reasonable
approach of all three.
The only question I have there is whether the 'netdev model' they all
have actually makes sense. What I mean by that is that they all assume
they have a default channel (using untagged frames, initial netdev,
initial netdev respectively for (1) - (3)).
In 802.11, we don't have such a default channel - you can add/remove
virtual netdevs on the fly. But if you want to do that, then you can't
use IFLA_LINK and the normal link type, which means custom netlink and
custom userspace etc. which, while we do it in wifi, is bothersome.
Here I guess the question would be whether it makes sense to even remove
the default channel, or retag it, or something like that. If no, then to
me it all makes sense to just model rmnet. And even if it *is* something
that could theoretically be done, it seems well possible to me that the
benefits (using rtnl_link_register() etc.) outweigh the deficits of the
approach.
I'm tempted to take a stab at breaking out rmnet_link_ops from the rmnet
driver, somehow giving it an alias of 'wwan-channel' or something like
that, and putting it into some sort of small infrastructure.
Anyone else have any thoughts?
Thanks,
johannes
