Expose some initial interfaces in the mount-related syscalls to select
the desired VFSRootContext, by specifying the VFSRootContext index
number.
For now there's still no way to create a different VFSRootContext, so
the only valid IDs are -1 (for currently attached VFSRootContext) or 1
for the first userspace VFSRootContext.
The new mechanism is basically adding or removing symbolic links to
device nodes in /dev. These symbolic links are located in the directory
of /tmp/system/devicemap/nodes/{block,char} which contain subdirectories
for major number allocation, which then hold these symbolic links.
An interested userspace program could then open an inode watcher on the
subdirectories which hold the symbolic link for added or removed links
to indicate hotplug events of insertion or removal of a device.
In case the user requests this, init can drop directly to a shell
without trying to spawn SystemServer.
To test this on x86-64, run:
```
Meta/serenity.sh run x86_64 GNU "init_args=emergency"
```
Also, init will drop to emergency shell if mounting filesystems with
`mount -a` failed for some reason.
This functionality can be useful in many cases.
For example, if the user needs to perform a command that must not alter
a corrupted filesystem state, then this mode is useful as the filesystem
should be mounted in read-only mode.
Another example is the ability to get a functioning system in case
SystemServer behaves badly or inconsistently, or the user specified a
wrong fstab entry, so proceeding to boot is probably a bad option.
Let's make SystemServer simpler by not involving it with the basic
system initialization sequence.
That initialization sequence can be done in another program that
theoretically can be put in another filesystem.
Co-authored-by: Tim Schumacher <timschumi@gmx.de>
