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