[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180328162811.GB15827@lunn.ch>
Date: Wed, 28 Mar 2018 18:28:11 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Arnd Bergmann <arnd@...db.de>
Cc: Ioana Ciornei <ioana.ciornei@....com>,
gregkh <gregkh@...uxfoundation.org>,
Laurentiu Tudor <laurentiu.tudor@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Stuart Yoder <stuyoder@...il.com>,
Ruxandra Ioana Ciocoi Radulescu <ruxandra.radulescu@....com>,
Razvan Stefanescu <razvan.stefanescu@....com>,
Roy Pledge <roy.pledge@....com>,
Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
> I'm still not convinced either way (high-level or low-level
> interface), but I think
> this needs to be discussed with the networking maintainers. Given the examples
> on the github page you linked to, the high-level user space commands
> based on these ioctls
>
> ls-addni # adds a network interface
> ls-addmux # adds a dpdmux
> ls-addsw # adds an l2switch
> ls-listmac # lists MACs and their connections
> ls-listni # lists network interfaces and their connections
>
> and I see that you also support the switchdev interface in
> drivers/staging/fsl-dpaa2, which I think does some of the same
> things, presumably by implementing the switchdev API using
> fsl_mc_command low-level interfaces in the kernel.
Hi Arnd
I agree that switchdev and devlink should be the correct way to handle
this. The low level plumbing of the hardware should all be
hidden. There should not be any user space commands needed other than
the usual network configuration tools and devlink.
Andrew
Powered by blists - more mailing lists