Re: ifp->if_capabilities needs to grow

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).
>