Date: Mon, 11 Oct 2021 20:14:26 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Hans Petter Selasky <hps@selasky.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: ifp->if_capabilities needs to grow Message-ID: <YWRw8r1DlGx4CEIG@kib.kiev.ua> 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>
index | next in thread | previous in thread | raw e-mail
On Mon, Oct 11, 2021 at 10:10:27AM -0700, John Baldwin wrote: > On 10/11/21 2:15 AM, Hans Petter Selasky wrote: > > Hi, > > > > As part of ongoing TLS RX work, it has become apparent that > > if_capabilities and if_capenable needs to grow to 64-bits at least. > > > > Right now those fields are 32-bits, and are fully utilized. > > > > The question is how this can be implemented so that a MFC to 13-stable > > is possible. > > > > The most simple solution is to substitute "int" by "uint64_t", but that > > will break the ABI. > > It breaks the kernel and userland ABIs, and for ifreq it is not easy to > notice as the size of ifreq wouldn't change. > > > Another solution is to use an array of "int" variables. > > > > A third solution is to abandon the two fields when MFC-ing, and adding > > two new 64-bit fields in the end of the ifnet. > > > > Also the user-space API for ifconfig is subject to change. > > 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). > > My only worry is that we are adding new bits at an increasing rate and > that the need for IFCAP3_* might not be that far off. If we add new > ioctls that use ifr_buffer then it's easier to support adding new words > in the future. It would also allow fetching all of the capabilities in > one ioctl. For these ioctls I would suggest using ifr_buffer where > 'buffer' points to an array of integers. SIOCSIFCAPARRAY would point > 'buffer' at the array of new capabiltiies. SIOGSIFCAPARRAY would point > 'buffer' at an array of 2x the number of integers. (So it would be an > error for 'length' to not be a multiple of 2 * sizeof(int).) The first > half of the array would return if_capabilities bits (equivalent to > if_reqcap today), the second half would return the if_capenable bits > (equivalent to if_curcap today). The existing ioctls would just return > the first words. > > If we were to use arrays for the ioctls, the kernel could either switch > to arrays in struct ifnet (harder to MFC), or just add the new if_cap*2 > fields and populate the arrays for the userland buffer based on those. Might be it is time to switch to TLV/nvlists there?help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YWRw8r1DlGx4CEIG>