Re: Should linuxkpi linux_file_ioctl support flexible array copy?

> On Feb 14, 2026, at 11:50 AM, yi zishun <[email protected]> wrote:
> 
> On Fri, Feb 13, 2026 at 09:42:58PM +0800, Zhenlei Huang wrote:
> > Probably it does not matter. It is good to keep the ABI stable, well that implies
> > stable ABI cross different versions of OS, but not different OSes. Am I right ?
> >
> > I think make it work first, make it better second !
> 
> Thanks for your kind reply!
> 
> You are absolutely right. I think the best way forward is to change the
> ABI to use an explicit pointer rather than a flexible array, which
> conforms better to the FreeBSD style.

FreeBSD has Linuxulator ( Linux Binary Compatibility ) to run unmodified
Linux applications. So if your goal is that, then I think the Linuxkpi should
be extended to support ioctl request with flexible arrays. I think that is
one typical case to maintain *stable ABI* across different OSes ;)

> 
> However, I noticed that the Linux ioctl scheme is designed to pass the
> raw user space pointer to the low level driver. Currently, the FreeBSD
> linuxkpi only provides a "fake" user space pointer (backed by kernel
> memory), which cannot be used for parameters involving flexible arrays.
> This implementation does not seem to fully conform to the Linux ioctl
> scheme.
> 
> Do you think improving linuxkpi to support this pattern (flexible arrays
> in ioctl) is worth pursuing in the long run? It seems like a valuable
> compatibility improvement for future driver ports.

I did a quick look at the design of ioctl handling of FreeBSD and the
LinuxKPI. I think it is doable to improve them to handle flexible
arrays.

A straight forward way is, pass both the userspace pointer along
with the kernel's one to the driver, since the driver knows better
whether the ioctl want to process flexible array or not.

Another approach could be wrapping the handling of copyin / copyout
of ioctl request entirely by the kernel, as the kernel has some
improvements ( use local variable rather than malloc for small ioctl
requests ), so drivers can also benefit it when possible.

Either way may want some efforts and I see KBI changes. So it is
important to know how many drivers want this feature.

> 
> But as you said, "make it work first, make it better second", I will use
> the above method to get it working first.

Good luck with you !

> 
> Best Regards,
> Zishun Yi

Best regards,
Zhenlei