Re: [Vserver] [RFC][PATCH 0/9] separate internal kernel pids from userspace ones
On Mon, 2005-10-24 at 23:09 +0100, Martin wrote: > On Mon, 2005-10-24 at 18:21 +0200, Dave Hansen wrote: > > I'm working on a project to checkpoint and restart processes. Obviously, > > after a > > process dies, and is "transparently" restarted, it might get confused > > because > > its pid changed. (This is one of many issues, but I'm starting with pids) > I've seen some process checkpointing / migration patches for Linux in > the past. Have you had a look around to see if there is anything else > that already does this. Perhaps I'm getting the wrong end of the stick > but it might save you some time. Basically, all of the existing patches were meant to be just that: patches. My goal is to get everything into the mainline kernel. It turns out that it's much easier to step back and rethink what we need, and recode it to the current kernel standards than try to shoehorn something that exists into shape. Also, many of the existing projects try to do too much in userspace. That said, I'm getting lots of inspiration from existing projects like vserver. -- Dave ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] [RFC][PATCH 0/9] separate internal kernel pids from userspace ones
On Mon, 2005-10-24 at 18:21 +0200, Dave Hansen wrote: > I'm working on a project to checkpoint and restart processes. Obviously, > after a > process dies, and is "transparently" restarted, it might get confused because > its pid changed. (This is one of many issues, but I'm starting with pids) I've seen some process checkpointing / migration patches for Linux in the past. Have you had a look around to see if there is anything else that already does this. Perhaps I'm getting the wrong end of the stick but it might save you some time. Cheers, - Martin PS Herbert, I have not forgotten the promise I made to test portability - I'm doing 4 jobs at the moment and I'm kinda short of time. However when I've got time I have SPARC, SMP and non, POWER and MIPS covered, depending on the owner's cooperation / transport / being able to make them work I can also do ARM, M68K and ALPHA. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] [RFC][PATCH 0/9] separate internal kernel pids from userspace ones
On Mon, Oct 24, 2005 at 06:21:26PM +0200, Dave Hansen wrote: > I'm working on a project to checkpoint and restart processes. Obviously, > after a > process dies, and is "transparently" restarted, it might get confused because > its pid changed. (This is one of many issues, but I'm starting with pids) > > I don't want to change the kernel's internal idea of pids, but I would like to > have a new pid namespace which a process can see. This means finding all the > places where the kernel returns a pid to userspace, and returning something > different. The following patch series implements a very simple mechanism for > doing that. > > I know the stuff in the end is relative junk (just for testing), but does > anybody see a good reason that we can't start merging something resembling the > first couple patches? some patches/parts seem to be still missing ... maybe they were caught by the spam filter? is there a place to download them? TIA, Herbert > ___ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] [RFC][PATCH 0/9] separate internal kernel pids from userspace ones
I'm working on a project to checkpoint and restart processes. Obviously, after a process dies, and is "transparently" restarted, it might get confused because its pid changed. (This is one of many issues, but I'm starting with pids) I don't want to change the kernel's internal idea of pids, but I would like to have a new pid namespace which a process can see. This means finding all the places where the kernel returns a pid to userspace, and returning something different. The following patch series implements a very simple mechanism for doing that. I know the stuff in the end is relative junk (just for testing), but does anybody see a good reason that we can't start merging something resembling the first couple patches? ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
