Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver

[Aleksander Morgado]

Hey!

>
> But what if we implement the QMI multiplexing management part in the
> kernel? This way the kernel will take care about modem-to-host
> communication protocols and interfaces, and provides userspace with a
> single WWAN device (possibly with multiple network and network
> management interfaces).
>
> I do not propose to fully implement QMI protocol inside the kernel,
> but implement only a mux management part, while passing all other
> messages between a "modem" and a userspace software as-is.
>
> What pros and cons of such a design do you see?
>

The original GobiNet driver already provided some QMI protocol
implementation in the driver itself. In addition to initial device
setup as you suggest, it also allowed userspace applications to
allocate and release QMI clients for the different services that could
be used independently by different processes. Not going to say that
was the wrong way to do it, but the implementation is definitely not
simple. The decision taken in qmi_wwan to make the driver as simple as
possible and leave all the QMI management to userspace was quite an
important one; it made the driver extremely simple, leaving all the
complexity of managing the protocol to userspace, and while it had
some initial drawbacks (e.g. only one process could talk QMI at a
time) the userspace tools have evolved to avoid them (e.g. the
qmi-proxy).

I wrote some time ago about this, maybe it's still relevant today:
Blogpost https://sigquit.wordpress.com/2014/06/11/qmiwwan-or-gobinet/,
Article in PDF https://aleksander.es/data/Qualcomm%20Gobi%20devices%20on%20Linux.pdf

Making the driver talk QMI just for device setup would require the
kernel to know how the QMI protocol works, how QMI client allocations
and releases are done, how errors are reported, how is the format of
the requests and responses involved; it would require the kernel to
wait until the QMI protocol endpoint in the modem is capable of
returning QMI responses (this could be up to 20 or 30 secs after the
device is available in the bus), it would require to have possibly
some specific rules on how the QMI clients are managed after a
suspend/resume operation. It would also require to sync the access to
the CTL service, which is the one running QMI service allocations and
releases, so that both kernel and userspace can perform operations
with that service at the same time. It would need to know how
different QMI capable devices behave, because not all devices support
the same services, and some don't even support the WDA service that
would be the one needed to setup data aggregation. There is definitely
some overlap on what the kernel could do and what userspace could do,
and I'd say that we have much more flexibility in userspace to do all
this leaving all the complexity out of the kernel driver.

ModemManager already provides a unified API to e.g. setup multiplexed
data sessions, regardless of what the underlying kernel implementation
is (qmi_wwan only, qmi_wwan+rmnet, ipa+rmnet, bam-dmux, cdc_mbim...) .
The logic doing all that is extremely complex and possibly full of
errors, I would definitely not want to have all that logic in the
kernel itself, let the errors be in userspace! Unifying stuff in the
kernel is a good idea, but if you ask me, it should be done in a way
that is as simple as possible, leaving complexity to userspace, even
if that means that userspace still needs to know what type of device
we have behind the wwan subsystem, because userspace will anyway need
to know all that.

-- 
Aleksander
https://aleksander.es