From nobody Tue Oct 12 11:14:06 2021 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9634017ED988 for ; Tue, 12 Oct 2021 11:14:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTCjS3GTTz4t0v; Tue, 12 Oct 2021 11:14:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8E15A260245; Tue, 12 Oct 2021 13:14:18 +0200 (CEST) Subject: Re: ifp->if_capabilities needs to grow To: Konstantin Belousov Cc: John Baldwin , "freebsd-arch@freebsd.org" References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> <5254ef46-e158-ef58-05eb-3d85c04a7612@selasky.org> From: Hans Petter Selasky Message-ID: <206cc4d8-6f69-8f94-b8d6-cf92d71bd28d@selasky.org> Date: Tue, 12 Oct 2021 13:14:06 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HTCjS3GTTz4t0v X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N 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). >> >