Re: ifp->if_capabilities needs to grow

Hi Konstantin,

It took 20 years to reach ifcap2 . Can we assume that it will take 
another 20 years to reach ifcap3 ?

--HPS

On 10/12/21 12:43 PM, Konstantin Belousov wrote:
> 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).
>>
>