netdev - Re: [PATCH net-next 1/2] net: usb: qmi_wwan: add qmap id sysfs file for qmimux interfaces

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]

Message-ID: <87mtwudene.fsf@miraculix.mork.no>
Date:   Wed, 27 Jan 2021 08:26:13 +0100
From:   Bjørn Mork <bjorn@...k.no>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Daniele Palmas <dnlplm@...il.com>,
        "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-usb@...r.kernel.org,
        Aleksander Morgado <aleksander@...ksander.es>
Subject: Re: [PATCH net-next 1/2] net: usb: qmi_wwan: add qmap id sysfs file
 for qmimux interfaces

Jakub Kicinski <kuba@...nel.org> writes:
> On Mon, 25 Jan 2021 17:14:28 +0100 Bjørn Mork wrote:
>> Daniele Palmas <dnlplm@...il.com> writes:
>> 
>> > Add qmimux interface sysfs file qmap/mux_id to show qmap id set
>> > during the interface creation, in order to provide a method for
>> > userspace to associate QMI control channels to network interfaces.
>> >
>> > Signed-off-by: Daniele Palmas <dnlplm@...il.com>  
>> 
>> Acked-by: Bjørn Mork <bjorn@...k.no>
>
> We got two patches adding new sysfs files for QMI in close succession -
> is there a sense of how much this interface will grow over time?

The honest answer is no.

I do not expect this interface to grow at all.  But then I didn't expect
it to grow before the two recent additions either...  Both are results
of feedback from the userspace developers actually using this interface.

If I try to look into the future, then I do believe the first addition,
the "pass_through" flag, makes further changes unnecessary.  It allows
the "rmnet" driver to take over all the functionality related to
qmap/qmimux.  The rmnet driver has a proper netlink interface for
management.  This is how the design should have been from the start, and
would have been if the "rmnet" driver had existed when we added qmap
support to qmi_wwan.  Or if I had been aware that someone was working on
such a driver.

So why do we still need this last addition discussed here? Well, there
are users of the qmi_wwan internal qmimux interface.  They should move
to "rmnet", but this might take some time and we obviously can't remove
the old interface in any case. But there is a design flaw in that
interface, which makes it rather difficult to use. This last addition
fixes that flaw.

I'll definitely accept the judgement if you want to put your foot down
and say that this has to stop here, and that we are better served
without this last fix.

> It's no secret that we prefer netlink in networking land.

Yes.  But given that we have the sysfs interface for managing this
qmimux feature, I don't see netlink as an alternative to this patch.

The same really applies to the previous sysfs attribute, adding another
flag to a set which is already exposed as sysfs attributes.

The good news is that it allowed further qmimux handling to be offloaded
to "rmnet", which does have a netlink interface.

Bjørn