Hello Aleksander, On Mon, Jul 26, 2021 at 11:11 AM Aleksander Morgado <aleksander@xxxxxxxxxxxxx> wrote: >> 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. Ouch! All these QMI internals are like a can of worms. Each time I start thinking that I learned something I face another complexity. Many thanks for your detailed reply and for your blogpost, for me it was quite helpful for understanding to see a side by side comparison of approaches! The argument for keeping drivers minimalistic to keep the system stable sounds reasonable. But I am still feeling uncomfortable when a userspace software manages a device at such a low level. Maybe it is a matter of taste, or maybe I still do not realize the whole complexity. Anyway, in the context of your clarification, I should be more careful in the future with calls to implement QMI in the kernel :) -- Sergey
