netdev - Re: [PATCH net-next 0/2] net: usb: qmi_wwan implement tx packets aggregation

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Y1AcU0CH/j69uvwx@kroah.com>
Date:   Wed, 19 Oct 2022 17:48:35 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     Daniele Palmas <dnlplm@...il.com>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, linux-usb@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/2] net: usb: qmi_wwan implement tx packets
 aggregation

On Wed, Oct 19, 2022 at 05:04:31PM +0200, Bjørn Mork wrote:
> Daniele Palmas <dnlplm@...il.com> writes:
> > I'm aware that rmnet should be the preferred way for qmap, but I think there's
> > still value in adding this feature to qmi_wwan qmap implementation since there
> > are in the field many users of that.
> >
> > Moreover, having this in mainline could simplify backporting for those who are
> > using qmi_wwan qmap feature but are stuck with old kernel versions.
> >
> > I'm also aware of the fact that sysfs files for configuration are not the
> > preferred way, but it would feel odd changing the way for configuring the driver
> > just for this feature, having it different from the previous knobs.
> 
> It's not just that it's not the preferred way.. I believe I promised
> that we wouldn't add anything more to this interface.  And then I broke
> that promise, promising that it would never happen again.  So much for
> my integrity.
> 
> This all looks very nice to me, and the results are great, and it's just
> another knob...
> 

Please no more sysfs files for stuff like this.  This turns into
vendor-specific random files that no one knows how to change over time
with no way to know what userspace tools are accessing them, or if even
anyone is using them at all.

Shouldn't there be standard ethtool apis for this?

> But I don't think we can continue adding this stuff.  The QMAP handling
> should be done in the rmnet driver. Unless there is some reason it can't
> be there? Wouldn't the same code work there?

rmnet would be better, but again, no new sysfs files please,

thanks,

greg k-h