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.
