Re: ifp->if_capabilities needs to grow

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?