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
