This function is a Luna alternative to fork() and exec().
Why? Simply because I can't figure out for the life of me how to implement a working fork().
So meanwhile, we have spawn() as a replacement. exec() still exists, though.
The only thing doing weird stuff is exec(), so that's commented out and throws ENOSYS right now.
But we have two user tasks running in parallel, isolated from each other!
We should start to drop the old InitRD API, which only allows for files to be loaded from the initrd, and which forces pathnames to be relative (bin/init)
With VFS, we can load any kind of file from any kind of filesystem, and using paths that make sense (/bin/init)
Finally, resolve_path: a function which takes a path (/etc/fstab for example), and walks the VFS:
In this case, it would start with the root FS node, and ask it: "do you have a directory/file named etc?"
The node could say 'yes', 'no', or 'i'm not a directory, I'm a file' (should not be the case for the VFS root, but for the other ones it could be)
If it says yes, we continue and ask the child if it has a file named fstab. Etc...
The exit() libc function already accepted an integer, but didn't pass it on to the kernel since we had no mechanism for it to do that.
Now, the kernel stores a task's exit status to display it later (and in the future, return it to userspace via wait()/waitpid())
IT ACTUALLY WORKS NOW.
Why wasn't it working? Oh, because I was not setting already present page tables's permissions to user mode. Just a little bug. THAT I SPENT DAYS TRYING TO FIND
Anyways, it works now. Such a relief...
Yes, that's not completely-from-scratch.
But let's be honest, am I going to do everything from scratch? Probably not. I'm not making my own bootloader.
And making a proper smaller-than-4-KB allocator is not something I want to do.
Plus, liballoc works perfectly in this rewrite, seeing as the MM code actually works, instead of leaking all your poor memory
And liballoc_{lock, unlock} can be actually defined, since we have spinlocks here!
