> I'll take humans over bees any day. Real OS's, with real operating
> systems. Monolithic, because they CAN stand alone, and in fact do most
> of their stuff without needing hand-holding every single minute.
> General-purpose instead of being able to do just one thing.
This has been suggested many times, but I am going to suggest this
again. I honestly see this problem as half user space, half kernel
space. I also see it as a solvable solution.
I believe QNX has this feature, and I greatly like it, even if QNX
doesn't. It seems like a good idea.
Session management, say as found in Gnome, is similar, but a much
smaller scale idea. Here are the problems and solutions as I see them.
I hope that you all will take me seriously though I have had no OS
design experience, and have recently had unsightly classes (caused by my
ignorance and, in some cases, arrogance).
Process migration: You tell the kernel, I want to take this process
home with me in a file to load on the _SAME_ archetecure, with hopefully
the same file system, and definitely the _SAME_ OS. Kernel creates 1
file. This file is basically a core dump, it saves ALL memory and CPU
state for that application. It then tags onto the end, any necessary
kernel structures that can't be remade when opening the "app file."
Problems as I see them:
1) Open files: One way around this, and in which environment this would
be most useful, would be an environment where all servers/workstations
have the same "user" file systems. Provided via coda, nfs, or similar.
I believe this is easy to do since you have file descriptors, you should
be able to provide path name instead of inode or file descriptors. The
kernel then could easily recreate state.
1b) Non similar file system space: The kernel should allow the user to
say, well this wont be the same file system view... please append all
the files I am using and give them a new name. I am not exactly sure
how this would work, but it is possible.
2) Network connections (and hardware state for root device), and other
non-transferable things: Sorry, the kernel should easily be able to say
"This is a serial/network device/connection, we can't migrate this
process.
2b) Some exceptions would be such special files as /dev/dsp and
/dev/audio. This could be saved as what state they were in and that we
had control.
Honestly, I view this as a wonderful feature. I also have some ideas of
where it would be useful, but don't really have any need at the moment.
At the point where there is need, app state may just be easier to save
in the app than to migrate the process. I thinkt he biggest gain for
this would be in BeoWolf or other cluster environments.
If this is a crazy idea or has problems, please don't flame me, just
enlighten me. If there are tools that do just this, please let me
know. I imagine suspend to disk is a similar idea since it has to save
state... just wouldn't have so many special cases.
Trever Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/