Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Oct 2021 10:10:27 -0700
From:      John Baldwin <jhb@FreeBSD.org>
To:        Hans Petter Selasky <hps@selasky.org>, "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org>
Subject:   Re: ifp->if_capabilities needs to grow
Message-ID:  <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org>
In-Reply-To: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org>
References:  <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35447c40-a939-820f-446c-f3a1c69eadc5>