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

On Tuesday 28. January 2020 17.52.21 Andrew Warkentin wrote:
> 
> This is the closest thing to a summary that I have at the moment:
> 
> https://gitlab.com/uxrt/uxrt-toplevel/blob/master/architecture_notes

I felt that this deserved a separate message. :-)

Firstly, you've got your work cut out with all those goals and criteria, but I 
think that it is always useful to document such thoughts and ideas, although I 
find that it can also be rather overwhelming, too. I haven't read through 
everything and have only taken a quick look because there is a lot to read and 
digest on that page.

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.)

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).

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.

Anyway, I could probably continue like this for many more pages, but I hope 
that my words are some form of encouragement, and I look forward to more 
discussion if that interests anyone.

Paul