Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> writes: >> At least with a recent modern distro I can't imagine this to be an >> issue. I expect we could have a kernel build option that removed the >> mknod system call and a modern distro wouldn't notice. > > A few things beyond named pipes will break. PCMCIA I believe still > depends on ugly mknod hackery of its own. You also need it for some > classes of non detectable device. > > Basically though you could. Ah yes fifos. I had forgotten mknod created them. I am half surprised there isn't a mkfifo system call. >> For migration with direct access to real hardware devices we must treat >> it as hardware hotunplug. There is nothing else we can do. > > That is demonstrably false for a shared bus or a network linked device. > Consider a firewire camera wired to two systems at once. Consider SAN > storage. Sort of. If you are talking to the device directly there is usually enough state with the path changing that modelling it as a hotunplug/hotplug is about all that is practical. There is all of that intermediate state for in progress DMAs in the end system controllers etc. Now if you have a logical abstraction like a block device in between the program and the SAN storage, then figuring out how to preserve device names and numbers becomes interesting. At least far enough to keep device and inode numbers for stat intact. A fully general solution for preserving device names, and numbers requires rewriting sysfs. I expect a lot of the infrastructure someone needs is there already from my network namespace work but after having done the network namespace I am sick and tired of manhandling that unreasonably conjoined glob of device stuff. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
