Re: ses ioctl API/ABI stability

On Thu, Aug 26, 2021 at 2:21 AM David Chisnall <theraven@freebsd.org> 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.