Re: UX/RT Architecture (was Re: Compatibility of microkernel systems with legacy OSes)

On 1/29/20, Paul Boddie <[email protected]> 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.