Re: ses ioctl API/ABI stability

From: Alan Somers <>
Date: Thu, 26 Aug 2021 09:50:01 -0600
On Thu, Aug 26, 2021 at 2:21 AM David Chisnall <> wrote:

> 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

Wild.  I never thought about doing it that way.  In this case though, ses
isn't terribly useful for jails.  I'm going to use imp's gone_in API
instead, which I only discovered just this morning.
Received on Thu Aug 26 2021 - 15:50:01 UTC

Original text of this message