Hi Bjorn,

>> This series starts by moving the common definitions of the QMUX protocol to 
>> the
>> uapi header, as they are shared with clients - both in kernel and userspace.
>> This series then introduces in-kernel helper functions for aiding the 
>> handling
>> of QMI encoded messages in the kernel. QMI encoding is a wire-format used in
>> exchanging messages between the majority of QRTR clients and services.
> Interesting!  I tried to add some QMI handling in the kernel a few years
> ago, but was thankfully voted down.  See
> https://www.spinics.net/lists/netdev/msg183101.html and the following
> discussion. I am convinced that was the right decision, for the client
> side at least. The protocol is just too extensive and ever-growing to be
> implemented in the kernel. We would be catching up forever.

I think that even back then I said, that it has to be done as a proper 
subsystem if it has a chance to be in the kernel. So something similar to 
Phonet and CAIF where the service registration is handled by the kernel, but 
applications can be fully in userspace. None of this is actually brand new 
Qualcomm design since Nokia has had its Phonet long before QMI existed.

The real importance is that Qualcomm is behind this and wants to get this done 
a clean way with a proper API. The /dev/qmi thing was a pretty broken 
interface. Any subsystem has to support multiple QMI devices. Even if this is 
unlikely in a phone design, it has to be supported so that attaching two USB 
QMI based dongles does not end up with some pointless errors.



Reply via email to