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] [day] [month] [year] [list]

Message-ID: <20210128180058.3224e376@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 28 Jan 2021 18:00:58 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Bjørn Mork <bjorn@...k.no>
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

On Wed, 27 Jan 2021 08:26:13 +0100 Bjørn Mork wrote:
> Jakub Kicinski <kuba@...nel.org> writes:
> > 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.

Thanks for the explanation. I'll trust you on this one :)

I applied v2 and added the acks from v1.