Re: [RFC PATCH net-next] ipmr: ip6mr: APIs to support adding more than MAXVIFS/MAXMIFS

[Andrew Lunn <andrew@lunn.ch>]

> That particular goal by Eric isn't exactly my goal. I extended his
> approach to be more inline with the latest feedback he got. My
> application is written for an embedded router and for it
> /usr/include/linux/mroute.h is coming from the
> include/uapi/linux/mroute.h. So, the new structure mfcctl_ext can be
> used by the application.

Hi Stephan

That however is not the general case. Any new API you add needs to
support the general case, not just work for you. This needs to work
for Debian, Redhat, OpenWRT, Yocto etc, where often a copy of the
kernel headers are used.

> This proposal doesn't change any existing ones such as MRT_ADD_MFC,
> MRT_ADD_VIF, MRT6_ADD_MFC and MRT6_ADD_MIF as they are still using the
> unchanged MAXVIFS. So, if the applications such as quagga still use the
> existing mroute.h it should still be working with the 32 vifs
> limitation.

Agreed, you have not broken the existing code. But you have also not
added something which is a good way forward for quagga, mrouted etc,
to support arbitrary number of VIFS. I doubt the community will allow
this sort of band aid, which works for you, but not many others. They
will want a proper generic solution.

     Andrew