Date: Tue, 12 Oct 2021 11:20:11 +0200 From: Hans Petter Selasky <hps@selasky.org> To: John Baldwin <jhb@FreeBSD.org>, "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org> Subject: Re: ifp->if_capabilities needs to grow Message-ID: <5254ef46-e158-ef58-05eb-3d85c04a7612@selasky.org> In-Reply-To: <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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?5254ef46-e158-ef58-05eb-3d85c04a7612>