From nobody Thu Aug 26 08:18:56 2021 X-Original-To: freebsd-current@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 D122C1775F1F for ; Thu, 26 Aug 2021 08:18:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4GwG2n3bMvz3DB3 for ; Thu, 26 Aug 2021 08:18:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 560DFDE78 for ; Thu, 26 Aug 2021 08:18:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-148-130-214.range86-148.btcentralplus.com [86.148.130.214]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 574952C71B for ; Thu, 26 Aug 2021 09:18:56 +0100 (BST) Subject: Re: ses ioctl API/ABI stability To: freebsd-current@freebsd.org References: From: David Chisnall Message-ID: <3e491c4f-0c86-a860-d0ed-b657ce653e74@FreeBSD.org> Date: Thu, 26 Aug 2021 09:18:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 25/08/2021 22:19, Alan Somers wrote: > We usually try to maintain backwards compatibility forever. But is that > necessary for the ses(4) ioctls? There are several problems with them as > currently defined. They lack type safety, lack automatic copyin/copyout > handling, and one of them can overrun a user buffer. I would like to fix > them, but adding backwards-compatibility versions would almost negate the > benefit. Or, can we consider this to be an internal API, changeable at > will, as long as sesutil's CLI remains the same? > -Alan I've been pondering for a little while the possibility of using CUSE for compat ioctls (particularly for jails, but potentially in general). This might be a good candidate. If you rename ses and provide a CUSE implementation of ses that runs in a Capsicum sandbox with access to the new device then the worst that a type-safety bug can do is issue the wrong ioctl (but not an invalid one, because the kernel will catch that with the new interfaces). sesutil can move to the new interface and so only things that want to directly talk to the old interface (for example, sesutil in a FreeBSD 12 jail) will need to load the userspace compat interface. David