netdev - Re: [PATCH net-next 11/18] switchdev: remove old netdev_switch_port_bridge

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: <CAGVrzcZoLxjNWq1_4q0w6D7n4DLmjnr09vEj75GOyabmAHRkag@mail.gmail.com>
Date:	Wed, 1 Apr 2015 18:01:45 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	"Arad, Ronen" <ronen.arad@...el.com>
Cc:	Jiri Pirko <jiri@...nulli.us>, Netdev <netdev@...r.kernel.org>,
	Scott Feldman <sfeldma@...il.com>,
	roopa <roopa@...ulusnetworks.com>,
	Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH net-next 11/18] switchdev: remove old netdev_switch_port_bridge_setlink

2015-03-31 16:32 GMT-07:00 Arad, Ronen <ronen.arad@...el.com>:
> Let's say vendor X wants to expose features X1, X2, ...Xm,
> vendor Y wants to expose features Y1, Y2, ...Yn, etc.
> How this would be visible to the users via iproute2?
> We'll need keywords Kx1..Kxm, Ky1..Kn, etc. There is scalability issue here.
> The user has to figure out the keyword Kxj goes with feature Xj etc.
> There must be a better way.
>
> What I have in mind is a way for switchdevX driver to define the its options
> and the keywords that the user could use to control them in a generic way.
> The kernel will provide the mechanism to export that to user space such that
> A tool like iproute2 could present user-friendly interface which is context
> aware.
>
> It is important to allow for a generic interface that will not require a new
> patch to the user-space tool or to the kernel net core (or switchdev) infrastructure, whenever any such new feature is being exposed.
> Only the switchdev driver which exposes a new feature need a patch.

You are essentially proposing to do the same thing as OpenWrt's
swconfig is doing [1]: each driver exposes both "generic" (to some
degree) and custom attributes, which are discovered by user-space in a
generic way. I think this is part of what do not want here, because
that leaves room for vendors to implement feature XYZ, using the
kernel as a programming interface, but without making the in-kernel
API and code any consistent, hence failing part of its abstraction
role.

Things like this have existed for a long time, like NL80211 testmode,
or wext private ioctl()s, etc.. etc.. I don't think that leads to
better APIs being defined unfortunately.

[1]: https://lwn.net/Articles/571390/
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html