On Tuesday 28. January 2020 17.52.21 Andrew Warkentin wrote:
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?
I would personally concentrate on the conceptual penalties rather than any performance penalties, which is often the emphasis in these kinds of discussions. For example, it bothers me somewhat that people are enthusiastic about things like the NetBSD rump kernel which doesn't come across as a particularly elegant or coherent solution to me. One ends up with some alien component that must either be completely relied upon to just work or which demands its own kind of expertise.
This is not to say that NetBSD, to continue with that example, doesn't offer anything. In fact, my C library experiments with L4Re utilise Newlib which is mostly a derivative of NetBSD's C library. Meanwhile, Minix 3 could be described as a NetBSD variant given the volume of NetBSD code involved (despite the many #ifdefs to activate Minix-specific sections). Maybe that is what one really ends up with when adopting whole subsystems from an existing project.
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.
Nor do the BSDs, but it is the reliance on Linux-specific features that ends up hurting Free Software. We only need look at the Free Software desktops and their reliance on software which demands an increasingly monolithic and "opinionated" stack of Linux-specific software. Things like Debian GNU/Hurd and kFreeBSD, whatever their merits, suffer from this creeping monoculture.
[...]
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.
It depends on what your ambitions are for interoperability. From what I recall, the BSDs and maybe various proprietary Unix products sought to support ABI compatibility with Linux, meaning that you could run Linux executables - presumably Intel x86 flavoured - on those operating systems. (I think Spring also sought to support Solaris binaries in such a fashion, by the way.)
But I imagine that you're looking for source code compatibility. However, I don't think that portability should be too much of a concern for well- engineered software projects: we all lived with multiple Unix flavours and autotools for years and things went pretty well. And some projects deal with even more esoteric things like Mac OS X, Windows NT (and successors), and sometimes even their predecessors.
[Imported but perhaps not "containerized" drivers]
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).
My recent experiences with Linux drivers suggest that understanding what they do is arguably much better than relying on them to work, even in Linux! But particularly so if they end up in another environment altogether. The different driver frameworks in Linux are not well-documented, unless there's some O'Reilly book that everyone is supposed to buy.
My own experiments have separated components out into layers. This is partly for the conceptual convenience, but I also want flexibility in how components can be combined. Unfortunately, I don't have any real familiarity with QNX: I know it has a long and interesting history as a Unix-like system, but when looking at historically interesting systems, I tended to choose the ones that seemed more pertinent to the topics I was investigating at the time.
[...]
I'd be willing to cooperate on such libraries as long as they don't place unnecessary burdens on client code.
For some kinds of drivers, the logic should be pretty indifferent to what kind of framework they are used in, and fairly conventional functions implementing the principal operations should cover most of the work. (I say this with some confidence looking at the drivers I wrote for L4Re, even though most of them are rather simple.) Generally, frameworks are the things that tend to inhibit re-use because they start making demands on how everything is to be done in the system.
I thought a bit more about libraries after writing my last message, and I do think that there would be benefits in describing component interfaces, if only to have productive discussions about how functionality might be arranged in such systems. I would say that such elaboration of interfaces has been rather de-emphasised in things like L4Re, with libraries being used to hide away such details, but just as various modelling diagrams can help to understand software, so we might expect interface descriptions to help us reason a bit better about the systems we want to develop.
Paul