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

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