From: Sergey Ryazanov <email@example.com> To: Aleksander Morgado <firstname.lastname@example.org> Cc: "Bjørn Mork" <email@example.com>, "Stephan Gerhold" <firstname.lastname@example.org>, "Loic Poulain" <email@example.com>, "David S. Miller" <firstname.lastname@example.org>, "Jakub Kicinski" <email@example.com>, "Johannes Berg" <firstname.lastname@example.org>, "Bjorn Andersson" <email@example.com>, "Andy Gross" <firstname.lastname@example.org>, "Vinod Koul" <email@example.com>, "Rob Herring" <firstname.lastname@example.org>, "Network Development" <email@example.com>, linux-arm-msm <firstname.lastname@example.org>, email@example.com, devicetree <firstname.lastname@example.org>, "open list" <email@example.com>, firstname.lastname@example.org, ~email@example.com, "Jeffrey Hugo" <firstname.lastname@example.org> Subject: Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver Date: Tue, 27 Jul 2021 01:40:10 +0300 [thread overview] Message-ID: <CAHNKnsSeX00+oL7uuKw83fRb0zSJWndQXyQH8PvoKf59mFUYgg@mail.gmail.com> (raw) In-Reply-To: <CAAP7ucLDEoJzwNvWLCWyCNE+kKBDn4aBU-9XT_Uv_yetnX4hemail@example.com> Hello Aleksander, On Mon, Jul 26, 2021 at 11:11 AM Aleksander Morgado <firstname.lastname@example.org> 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
next prev parent reply other threads:[~2021-07-26 22:40 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-19 14:53 [RFC PATCH net-next 0/4] " Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 1/4] dt-bindings: dmaengine: bam_dma: Add remote power collapse mode Stephan Gerhold 2021-07-29 19:36 ` Rob Herring 2021-07-29 19:50 ` Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 2/4] dmaengine: qcom: " Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 3/4] dt-bindings: net: Add schema for Qualcomm BAM-DMUX Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver Stephan Gerhold 2021-07-19 16:01 ` Loic Poulain 2021-07-22 15:40 ` Stephan Gerhold 2021-07-24 11:25 ` Sergey Ryazanov 2021-07-26 8:10 ` Aleksander Morgado 2021-07-26 22:40 ` Sergey Ryazanov [this message] 2021-07-20 9:10 ` Sergey Ryazanov 2021-07-21 12:17 ` Stephan Gerhold 2021-07-24 10:22 ` Sergey Ryazanov 2021-07-19 15:43 ` [RFC PATCH net-next 0/4] " Jeffrey Hugo 2021-07-19 18:23 ` Stephan Gerhold 2021-07-19 23:13 ` Jeffrey Hugo 2021-07-22 14:51 ` Stephan Gerhold 2021-07-26 14:58 ` Jeffrey Hugo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAHNKnsSeX00+oL7uuKw83fRb0zSJWndQXyQH8PvoKf59mFUYgg@mail.gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).