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
| ||
|
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.
Powered by blists - more mailing lists