On Wed, Jun 25, 2025 at 2:36 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > > While I agree that a filesystem offers superior introspection and > > integration with standard tools, building this complex, stateful > > orchestration logic on top of VFS seemed to be forcing a square peg > > into a round hole. The ioctl interface, while more opaque, provides a > > direct and explicit way to command the state machine and manage these > > complex lifecycle and dependency rules. > > I'm not going to argue that you have to switch to this kexecfs idea > but... > > You're using a character device that's tied to devmptfs. In other words, > you're already using a filesystem interface. Literally the whole code > here is built on top of filesystem APIs. So this argument is just very > wrong imho. If you can built it on top of a character device using VFS > interfaces you can do it as a minimal filesystem. > > You're free to define the filesystem interface any way you like it. We > have a ton of examples there. All your ioctls would just be tied to the > fileystem instance instead of the /dev/somethingsomething character > device. The state machine could just be implemented the same way. > > One of my points is that with an fs interface you can have easy state > seralization on a per-service level. IOW, you have a bunch of virtual > machines running as services or some networking services or whatever. > You could just bind-mount an instance of kexecfs into the service and > the service can persist state into the instance and easily recover it > after kexec. This approach sounds worth exploring more. It would avoid the need for a centralized daemon to mediate the preservation and restoration of all file descriptors. I'm not sure that we can get rid of the machine-wide state machine though, as there is some kernel state that will necessarily cross these kexecfs domains (e.g. IOMMU driver state). So we still might need /dev/liveupdate for that.
