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
