On 1/29/20, Paul Boddie paul@boddie.org.uk wrote:
Given previous discussions about compatibility, I find it interesting that you have described specific details of certain features such as the naming of disks and partitions in the filesystem. I guess that you and I have different approaches: I would probably defer such details until later, maybe even leaving them open for different "personalities" or configurations of the system.
Indeed, I would say that a fair amount of the document could conceivably describe a kind of system personality that could be supported by other systems. To take the example of a password database exposed at /etc/passwd in the filesystem, all that would be needed to provide this in something like L4Re is a server pretending to be a file. (Of course, the provided filesystem mechanisms in L4Re arguably don't support the necessary modularity, which is
how I ended up looking into the matter.)
I've never really been a fan of multi-personality systems, and I'd say they are less relevant now than ever because of low diversity and ubiquitous hardware virtualization. There are only really two environments for which compatibility matters in most cases - Linux and Windows. Linux compatibility can be implemented in a natively Unix-like environment, and so can Windows compatibility (with Wine). If you really need to run an entire alternate OS environment it can just be virtualized.
Having things like personality-neutral services just complicates the design of the system. It's far easier if you can just write servers to the same API as applications (under UX/RT, all servers except for the root server will be completely normal processes). Multiple personality support would almost certainly make the minimalist file-oriented architecture I have planned a lot more difficult to implement.
One thing that I was looking for, and so it immediately jumped out, was the
choice of C library. It seems very fashionable for people to choose musl-libc (or however it is meant to be written), and there is certainly some persuasive material suggesting it to be a "better" choice than other C library implementations, but when I looked at it, I found there to be rather a lot of system calls sprinkled around in places where they seem like optimisations,
meaning that the assumption is that a syscall would be "obvious" or necessary at such a point in the code, whereas one might have expected a plain function call to something that may or may not incorporate a syscall.
Meanwhile, it also seemed that the library rather assumed a Unix-style collection of distinct syscalls, arguably making it less than ideal for adaptation to something like L4 with a minimal set of more generic syscall operations. Now I accept that your needs might be different from mine, but I
wouldn't mind knowing the rationale for your choice (and for anyone else's choice, musl-libc or otherwise, for that matter). In my own experiments, looking for the easiest option (as usual, although nothing was actually easy), there were a couple of other libraries that looked more malleable or more readily usable (dietlibc was easiest to build, Newlib was easier to imagine
modifying).
Under UX/RT the raw seL4 API won't be exposed at all because it's not stable. Only the Unix-like transport layer and VFS/process server APIs will be visible to user processes, and these will be in a "libroot" library separate from libc. For functions usually implemented as system calls on traditional Unix but not present in libroot, there will be another library separate from both libc and libroot. Programs written in non-C languages won't even have to link with libc at all.
I will say that quite a few of your architectural goals seem possible with something like Fiasco.OC as the microkernel, at least going from my limited
understanding of it and L4Re through experimentation. I would go as far to say that we probably have broadly similar goals: I think that a filesystem- oriented approach is persuasive and is broadly accepted, although its benefits are often badly communicated (the now-familiar Hurd promotion of "translators", for instance) or seem arcane (various stuff related to Plan 9). When people have sought to question the approach by offering alternatives, like the concept of namespaces in Spring, I would argue that they have largely replicated the concept of a filesystem whilst failing to recognise what the
benefits of a more generalised filesystem might be.
I had thought of using Fiasco.OC at one point but I settled on seL4 because it's much more lightweight and it's formally verified. There's also a runtime for Rust root servers on seL4 but not Fiasco (back when I was considering Fiasco, I wasn't planning to use Rust). Another big problem with Fiasco is that it apparently requires a process to map a page into its own address space to be able to grant access to it, whereas on seL4 a process can map pages into address spaces of other processes without having them mapped into its own.