Re: [RFC v2 10/16] luo: luo_ioctl: add ioctl interface

[Jason Gunthorpe <jgg@ziepe.ca>]

On Sun, Jul 06, 2025 at 05:33:04PM +0300, Mike Rapoport wrote:

> One of the points in Christian's suggestion was that ioctl doesn't have to
> be bound to a misc device. Even if we don't use read()/write()/link() etc,
> we can have a filesystem that exposes, say, "control" file and that file
> has the same liveupdate_ioctl() in its fops as we have now in miscdev.

IMHO for this application there is nothing wrong with a misc
device. The intention is for a single userspace process to use this as
some kind of request broker and provide the required policy layer.

Creating a VFS and then running ioctl inside the VFS just seems like
over-engineering to me. We can't really avoid the ioctls.

This is not really managing files in the sense of string named objects
with bytestreams associated with them.

I've also heard people saying things like configs were a mistake, so
I'm not so sure about this. IIRC VFS brings a bunch of standard use
models and their associated races that the kernel is forced to deal
with, while the simple ioctl here has none of that complexity.

> The cost is indeed a bit of boilerplate code to create the filesystem, but
> it would be easier to extend for per-service and containers support.

I don't think it really improves that. You still have a single policy
agent in userspace that has to control this thing. 

On the other side you'd have a much more complex serialization job
because you have to capture an open ended filesystem instead of the
much simpler u64 key/value scheme the ioctl is using.

Jason