Instantiating rmnet devices for data ports on QRTR-based modems

[Aleksander Morgado]

Hey,

> > > And an additional question I have; what if we start using QMAP also
> > > for qmi_wwan based modems that support it? I think it would be very
> > > similar to your current needs with QRTR/IPA, right? See
> > > https://lists.freedesktop.org/archives/libqmi-devel/2018-July/002935.html
> > > Maybe we can setup a common API in libqmi that brings up the muxed
> > > network interfaces for both cases in a common way?
> >
> > Yes, that exact thought stroke me as well while skimming through this
> > discussion. It would be nice if the API could abstract away the
> > differences wrt adding network devices etc, and just present a common
> > muxing API.
>
> I haven't personally dealt with QMAP so I'm not really sure what's
> going on there. The linked discussion does suggest a similar
> architecture of one "real" net interface (wwan0 for QMAP, rmnet_ipa0
> for QRTR/IPA) over which several "virtual" net ports are overlaid
> (qmimuxN for QMAP, rmnet_dataN for QRTR/IPA).
>
> Neither case would deal with QMI directly outside of the Bind Mux Data
> Port message though, as far as I can tell. So I'm not sure if this is
> an argument for keeping it in libqmi or not.
>

At this point, I start to prefer the idea of keeping it in libqmi, but
the logic should not be automatic on QmiDevice open. libqmi could
provide a common method to add/delete the muxed interfaces, and that
method would be implemented differently depending on what kernel
driver is in use. Then, upper layers like MM or other programs using
qmicli could trigger the instantiation of the virtual net devices as
part of the connection attempt procedure.

-- 
Aleksander
https://aleksander.es