Re: ses ioctl API/ABI stability

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