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: <YUjbYEHbjDFB1k3Y@lunn.ch>
Date:   Mon, 20 Sep 2021 21:05:04 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Stephen Suryaputra <ssuryaextr@...il.com>
Cc:     netdev@...r.kernel.org
Subject: 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ