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)
read() and close() are in unistd.h, but open() in fnctl.h.
I thought only the definitions for O_SOMETHING were in fnctl.h, but it is as it is.
Don't know why, but let's not anger the Unix gods.
The FILE* C API is pending as well.
Kernel: Implement a descriptor struct which stores the opened node and read offset, and give each task 8 of those.
Implement three syscalls: sys_read, sys_open and sys_close (sys_write still writes to the console instead of using a fd, for now)
Implement three new errors: ENOENT, EBADF and EMFILE.
libc: Implement the new errors, and the new syscalls in syscall().
Also fix _RETURN_WITH_ERRNO() to set errno correctly, which was making strerror() return null, thus crashing perror().
userspace: make init demonstrate the new file API.
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...
%m as a format specifier is a nonstandard glibc extension, but I like it so I'm implementing it.
What it does is print the value of strerror(errno), without consuming any arguments to printf().
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())
Since we already extract the symbols into a separate file which the kernel then uses for backtraces, this only brings us a smaller kernel, with no downsides :)
