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
