netdev - Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Dec 2020 08:44:29 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Hemant Kumar <hemantk@...eaurora.org>
Cc:     manivannan.sadhasivam@...aro.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, jhugo@...eaurora.org,
        bbhatt@...eaurora.org, loic.poulain@...aro.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver

On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote:
> This MHI client driver allows userspace clients to transfer
> raw data between MHI device and host using standard file operations.
> Driver instantiates UCI device object which is associated to device
> file node. UCI device object instantiates UCI channel object when device
> file node is opened. UCI channel object is used to manage MHI channels
> by calling MHI core APIs for read and write operations. MHI channels
> are started as part of device open(). MHI channels remain in start
> state until last release() is called on UCI device file node. Device
> file node is created with format
> 
> /dev/<mhi_device_name>
> 
> Currently it supports QMI channel. libqmi is userspace MHI client which
> communicates to a QMI service using QMI channel. libqmi is a glib-based
> library for talking to WWAN modems and devices which speaks QMI protocol.
> For more information about libqmi please refer
> https://www.freedesktop.org/wiki/Software/libqmi/

This says _what_ this is doing, but not _why_.

Why do you want to circumvent the normal user/kernel apis for this type
of device and move the normal network handling logic out to userspace?
What does that help with?  What does the current in-kernel api lack that
this userspace interface is going to solve, and why can't the in-kernel
api solve it instead?

You are pushing a common user/kernel api out of the kernel here, to
become very device-specific, with no apparent justification as to why
this is happening.

Also, because you are going around the existing network api, I will need
the networking maintainers to ack this type of patch.

thanks,

greg k-h