On 1/28/20, Martin Decky martin.decky@huawei.com wrote:
FYI: The microkernel-based OS Huawei is working on internally has Linux compatibility (both from the syscall API and from the drivers point of view) as one of its goals.
Is it natively Unix-like, or is the Linux compatibility layer some kind of containerized "penalty box" that doesn't really integrate into the system? Also, since you're not developing it publicly , that may limit its ability to compete with Linux, which of course has a completely open development model without copyright assignment. In addition, from one article I read, it sounded like even though it is going to be open source eventually, it was designed with the assumption that it would be running on tivoized devices with locked bootloaders, with no way for the user to get full control.
GNU Hurd obviously also tries to be GNU/Linux compatible (not on the syscall level, but on the glibc level). Many other microkernel-based systems (e.g. Genode, just to name one) maintain their own adaptation layers for hosting Linux device drivers.
From what I understand, Hurd doesn't implement a lot of
Linux-kernel-specific APIs.
On 1/28/20, Paul Boddie paul@boddie.org.uk wrote:
I actually think that most people agree with you on this, at least when confronted with the notion for the first time. But I don't think such considerations should overrule every other consideration: it reminds me of people in the English-speaking world (particularly in my country of origin)
who say that if they could be bothered to learn a foreign language, it would
be "something like Spanish that a lot of people speak", justifying the choice in terms of all the millions of individual speakers with whom they could be
having hypothetical conversations that, naturally, they wouldn't end up having anyway.
For my purposes, I would much rather have an OS that runs Linux programs natively rather than having to port every single application I want to run.
Your project being this one:
Is there a summary of it anywhere?
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 wonder whether people don't already rely on things like L4Linux for such functionality. However, I don't personally think that having boxed-up driver
frameworks is particularly elegant or plays to the strengths of microkernel- based paradigms. In L4Re, I found myself staring down bits of imported Linux
kernel code and wondering whether things might not have been easier - and most certainly clearer - had something been developed independently.
Yes, it's true that it's maybe not the most elegant way to run drivers, but I think it's a worthwhile trade-off for broad hardware support. As far as UX/RT is concerned it's not really that big a sacrifice because it will have relatively little vertical modularization anyway (e.g. instead of separate disk filesystem, partition driver, and disk device driver processes, all three will be incorporated into a single "disk server" process, much as on QNX; this should improve performance over most other microkernel OSes while not really sacrificing much as far as security or error recovery).
Of course, the real solution is to have a library of functionality that a variety of systems could use. Then, we wouldn't need to pick over the remains of some other project. Being familiar with this industry over a couple of decades, however, I am fully aware that people exhibit rather strong tendencies to insist that such cooperation is not possible, usually because of something super-special that they insist that only they are doing.
I'd be willing to cooperate on such libraries as long as they don't place unnecessary burdens on client code.