This new device uses the seeded Mersenne PRNG we use in the kernel.
This device is not meant for regular userspace use, but more for userspace to seed their own PRNGs from.
If the DeviceFS is mounted at /dev, this device can be found at /dev/random.
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!
Very bare-bones for now. Doesn't support arguments or environment (we don't have that stuff right now), and the executable is not a valid ELF, it terminates the task.
But it's a start!
We were previously looking at its segment registers to see if they were user-like, but this method is bad.
What is the task was executing a system call?
So now, we store that value at creation time.
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)
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...
