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

From: Jakub Kicinski <kuba@kernel.org>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: Daniele Palmas <dnlplm@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-usb@vger.kernel.org,
	Aleksander Morgado <aleksander@aleksander.es>
Subject: Re: [PATCH net-next 1/2] net: usb: qmi_wwan: add qmap id sysfs file for qmimux interfaces
Date: Thu, 28 Jan 2021 18:00:58 -0800	[thread overview]
Message-ID: <20210128180058.3224e376@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <87mtwudene.fsf@miraculix.mork.no>

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