Date: Tue, 12 Oct 2021 13:14:06 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: John Baldwin <jhb@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: ifp->if_capabilities needs to grow Message-ID: <206cc4d8-6f69-8f94-b8d6-cf92d71bd28d@selasky.org> In-Reply-To: <YWVm3adutP2mZ2JB@kib.kiev.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Konstantin, It took 20 years to reach ifcap2 . Can we assume that it will take another 20 years to reach ifcap3 ? --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?206cc4d8-6f69-8f94-b8d6-cf92d71bd28d>