Date: Tue, 12 Oct 2021 14:18:35 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: John Baldwin <jhb@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: ifp->if_capabilities needs to grow Message-ID: <YWVvC5xWtuGR4Efd@kib.kiev.ua> In-Reply-To: <206cc4d8-6f69-8f94-b8d6-cf92d71bd28d@selasky.org> References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> <5254ef46-e158-ef58-05eb-3d85c04a7612@selasky.org> <YWVm3adutP2mZ2JB@kib.kiev.ua> <206cc4d8-6f69-8f94-b8d6-cf92d71bd28d@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 12, 2021 at 01:14:06PM +0200, Hans Petter Selasky wrote: > Hi Konstantin, > > It took 20 years to reach ifcap2 . Can we assume that it will take another > 20 years to reach ifcap3 ? As John noted, we are accelerating the process. Besides TLS RX, we might have something like IPSEC_INLINE soon. As for inline IPSEC, we need to communicate the set of supported algorithms, which would require additional ioctl unless we switch (add advanced version of) CAP to use something more flexible. > > --HPS > > On 10/12/21 12:43 PM, Konstantin Belousov wrote: > > On Tue, Oct 12, 2021 at 11:20:11AM +0200, Hans Petter Selasky wrote: > > > Hi John, Konstantin and Gleb, > > > > > > There are basically three ways to solve the problem with adding TLSRX4 and > > > TLSRX6 capability bits. > > > > > > 1) Konstantin proposes to merge the API to nvlists. > > To make it clear. I do not propose to remove old ioctls. > > Just that in parallel to old way, a new nvlist-based ioctl would be added > > that has no limitation on the number of supported capabilities, by design. > > Old ifconfig continues to work, same as in scheme with XXXCAP2, but it > > kind of guarantees that we would not need XXXCAP3 ever. > > > > > > > > 2) John proposes to duplicate XXXCAP into XXXCAP2 to handle the new > > > capabilities. > > > > > > 3) Gleb proposes to free up existing bits. > > > > > > Looking at the different proposals I think John has the best one with > > > regards to MFC'ing. Then we don't change the meaning of any bits, and the > > > old ifconfig still works as expected. > > > > > > It's trivial to add a XXXCAP2 to ifconfig from what I can see. It already > > > modifying bit by bit, so no optimisations in there anyways. > > > > > > Do we have consensus? > > > > > > --HPS > > > > > > On 10/11/21 7:10 PM, John Baldwin wrote: > > > > One option is to perhaps add 'if_cap*2' with IFCAP2_* bits. It would > > > > be MFC'able (just add the new words at the end in the MFC), it's just a > > > > bit ugly compared to having an array. The other question is how to manage > > > > the ioctl. Right now the ioctl is an ifreq which takes a pair of ints > > > > (if_reqcap and if_curcap). If we use 'if_cap*2' then we can just add > > > > SIOCGIFCAP2 and SIOCSIFCAP2 to get/set the second words. We have done > > > > this with other fields (e.g. p_flag2). > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YWVvC5xWtuGR4Efd>