From nobody Mon Oct 11 17:10:27 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 23FE617E0587 for ; Mon, 11 Oct 2021 17:10:31 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSlft37Qzz4ZQs; Mon, 11 Oct 2021 17:10:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id A9F371321; Mon, 11 Oct 2021 17:10:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Hans Petter Selasky , "freebsd-arch@freebsd.org" References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> From: John Baldwin Subject: Re: ifp->if_capabilities needs to grow Message-ID: <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> Date: Mon, 11 Oct 2021 10:10:27 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; 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: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N 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