Re: [net-next PATCH v3 00/12] Flow API

[Thomas Graf <tgraf@suug.ch>]

On 01/22/15 at 10:44am, Jamal Hadi Salim wrote:
> On 01/22/15 10:37, Thomas Graf wrote:
> >On 01/22/15 at 10:28am, Jamal Hadi Salim wrote:
> 
> >>So if i am a vendor with my own driver, I can expose whatever i want.
> >
> >No. We will reject any driver change attempting to do so on this
> >list.
> >
> 
> Vendor provides a driver that exposes a discoverable interface
> (capabilities exposure that is facilitated).
> They dont need it to be part of the mainstream kernel.
> And they dont need any of your definitions.

An out of tree driver always had the possibility to register its own
Generic Netlink protocol and do exactly what you describe. The same
driver could also register as { xt, cls, act } module and export direct
hardware access to userspace through tc and iptables. The driver could
even register its own netfilter hook. You can abuse pretty much any
interface that has some form of registration mechansim from an out of
tree driver. We can't really control that.

I think we agree that the value of this model is that tools like nft,
OVS, SnabbSwitch, tc, [you name it] can use it to program the hardware
in a very generic manner from user space without requiring to move all
of that complexity to the kernel. In the very same way as the team
device exports most of the complexity to user space. Or for the same
reason routing protocol implementations were kept out of the kernel.

If a vendor exposes capabilities in a form that is not understood by
the well known tools it has zero value because the capabilities can't
be used. Any tool that would depend on such vendor specific bits that
are exported by out of tree drivers might as well use the existing
vendor SDKs which will always provide some additional functionality
because it doesn't have to compromise.