WIP: Add fork() #13

apio · 2022-10-15T16:03:10Z

apio commented

2022-10-15 16:03:10 +00:00

This PR adds initial support for fork(), which should work well along with exec(). Should not be merged until both fork() and exec() work well separately, and together.

apio added 1 commit 2022-10-15 16:03:11 +00:00

Add an initial fork() implementation 20cffdb66c

apio added 2 commits 2022-10-15 16:43:05 +00:00

libc: Add support for fork() e672f3994b

That doesn't mean it works.
Why doesn't it work??

Oh well...

More fork() work 7ab80014e1

apio commented

2022-10-15 16:45:44 +00:00

There is a problem here:

The child starts doing stuff with the parent's stack, since all addresses copied from the parent are directly what the parent set.

But if we map both stacks at the same place... we can't do that, since they share address spaces and modifying one will change the other.

Maybe patching the child stack? Not very usual... and hacky... let's try I guess.

There is a problem here: The child starts doing stuff with the parent's stack, since all addresses copied from the parent are directly what the parent set. But if we map both stacks at the same place... we can't do that, since they share address spaces and modifying one will change the other. Maybe patching the child stack? Not very usual... and hacky... let's try I guess.

apio added 1 commit 2022-10-15 16:59:15 +00:00

Kernel: add memmem 397b1a2819

apio added 2 commits 2022-10-15 18:31:07 +00:00

AddressSpace: make clone() perform a deep copy 16f797eeee

Which unlinks the address space from its parent.

fork() is almost working 145ea40945

apio added 1 commit 2022-10-16 07:58:23 +00:00

wait before letting the fork run for now 9070d17477

still is not working

why

apio added 1 commit 2022-10-16 12:31:24 +00:00

The kernel page directory is already there 08eb18307b

This doesn't fix anything...

apio commented

2022-10-16 12:48:02 +00:00

I don't understand.

Now address spaces are cloned, and copied, which means they have the same addresses but modifying memory in one doesn't get reflected in the other.

And yet, with an almost identical copy (except for the state of RAX), the parent continues execution normally, and the child does weird stuff with its stack (which has the same content as the parent's, at the same place), and ends off returning to 0.

WHY???

I don't understand. Now address spaces are cloned, and copied, which means they have the same addresses but modifying memory in one doesn't get reflected in the other. And yet, with an almost identical copy (except for the state of RAX), the parent continues execution normally, and the child does weird stuff with its stack (which has the same content as the parent's, at the same place), and ends off returning to 0. WHY???

apio added this to the (deleted) milestone 2022-10-16 16:22:45 +00:00

apio added the

enhancement

label 2022-10-16 16:22:48 +00:00

apio commented

2022-10-16 16:30:15 +00:00

I think my cheap solution for this right now is going be to introduce a spawn() function to spawn a new executable, and forget about fork() for now. At least until I can figure out why the hell it is working so weirdly.

apio closed this pull request

2022-10-16 16:30:15 +00:00

apio commented

2022-10-16 16:50:24 +00:00

Will have to come back to this in the future, since the idea is to be UNIX-like, but right now this is solved by commit 9b39d61. Now we can spawn() processes as much as we want!

Will have to come back to this in the future, since the idea is to be UNIX-like, but right now this is solved by commit [9b39d61](https://git.cloudapio.eu/apio/Luna/commit/9b39d618de3494a304fc5e7dae495f598c4a7968). Now we can spawn() processes as much as we want!

apio commented

2022-11-30 16:39:59 +00:00

Oh, by the way, the problem (which was solved LONG ago), was that we were setting the child's registers to the registers stored in the parent's Task structure. But we didn't save the parent's current context to that structure (why would we do so, that's only necessary during a context switch), and as such the child's registers were outdated (from the last context switch), clashing with up-to-date memory and stack pointers. The parent didn't mind since we didn't touch the current state of its registers.