l4-hackers

Download

l4-hackers@os.inf.tu-dresden.de

January 2020

4 participants
2 discussions

L4Re with GCC 9; Repositories and Roadmaps
by Paul Boddie 06 Feb '20

06 Feb '20

Hello and Happy New Year! Having been otherwise occupied so far this year, I decided to take the opportunity to revisit my L4 development environment that happens to use Debian unstable. It turns out that GCC 9 is now the supported toolchain version, and unfortunately, L4Re doesn't yet understand this new version. So, first of all, I wondered whether support for that is imminent. I did take a look at persuading the build system to work, but this seems to involve hunting down version-specific resources and defining new ones for the new version. I stopped when encountering some libstdc++ headers and wondering whether this isn't documented somewhere. = Repositories = It did occur to me that I might also be expecting updates for such things from the wrong channel. Since I have been using L4Re for a while, I still use the Subversion repositories made available from svn.l4re.org, referenced by the documentation on l4re.org. It seems that these repositories are not updated as frequently as the GitHub repositories, but maybe they serve as a kind of staging area for more stable releases. After giving up on using GCC 9, I decided to re-clone repositories in a Debian stable environment. This didn't go very well with the Subversion repositories: after a while of saturating my aging machine's I/O bandwidth, cloning (or checking out) tended to fail. The repomgr script, if re-run, seems to just delete everything and start again, so after a few tries I gave up. Meanwhile, using the GitHub repositories failed for different reasons. Previously, I have tended to get "index pack" and "missing object" errors with Git when cloning. There don't seem to be any decent remedies for this, with people suggesting tweaking compression, network, memory and other settings, manually fiddling with the "object database" and other such nonsense. The consensus might be that I do not have a powerful enough machine (only 1GB RAM) to clone even modestly-sized Git repositories. Nevertheless, it would be nice to be able to download some kind of release distribution. I somehow doubt that the world really needs to accommodate all the multi-gigabyte Linux kernel clones out there that differ by a few files, either. If I really want to version my modifications against the released code, I can always version control them myself (even using a more coherent version control system if I want). = Roadmaps = Such considerations led me to also consider what I have been wanting to use L4Re for and the notion of a roadmap, both my own and that of L4Re itself. It seems to me that L4Re, or parts of it, can form the basis of a usable system in its own right (as opposed to just hosting L4Linux). However, I don't see much development directed towards such a goal. (Actually, I don't really see much L4Re development at all.) It seems to me, as I may have mentioned before, that one crucial area of development that would be needed for my purposes is that of providing general- purpose filesystem support. To do that, it seems that a few separate issues need attention, amongst them the component architecture required to export file entries and contents to programs, and support in the C library so that programs can access files transparently. Since L4Re's filesystem support seems to require linking filesystem-specific libraries against programs and having those programs access filesystem data directly, as far as I can tell, a new component architecture is required. Meanwhile, it seems to me that uClibc, at least in the version offered by L4Re, does not offer a particularly coherent or convenient basis for integrating with such a component architecture. Consequently, I spent a fair amount of time last year investigating filesystem component architectures and alternative C library implementations. But I wouldn't mind knowing whether there are plans to remedy these deficiencies in L4Re or whether I should just plug away at such things by myself. (I can live with people saying that they don't care about the things that I happen to care about. No-one needs to make excuses here: even the Hurd people seem pretty unmotivated about getting people on board, although it can be said that within certain parameters, they at least have a system that meets their objectives to some degree.) = Some Thoughts = It rather looks like the amount of time I have to spend on L4Re-related development will be significantly reduced for the foreseeable future. In some respects, I feel that I have learned quite a bit, but in other respects, I feel that it has been a frustrating exercise to try and get up to speed with L4Re development. (And I hardly want to get started on my Fiasco development experience.) Although literature obviously exists about various L4 implementations, I don't feel that the documentation experience is coherent at all. Many of the pertinent details are also obscured by the focus on code-originating reference documentation. And where microkernel-based systems should be emphasising the nature of the interfaces between components, there instead seems to be a policy of hiding such details in the implementation details of various abstractions (implemented multiple times in an almost archaelogical fashion). Indeed, this latter policy is quite infuriating because it binds the developer to existing functionality and frameworks unnecessarily. So, when developing my components for low-end devices, I went along with L4Re framework classes due to an incomplete understanding of the IPC mechanisms (which also brought other irritations because those classes assume a more complete understanding), but also because interfacing with other components is not obvious when the protocols are squirreled away across multiple header and implementation files. I have even gone as far as to write my own interface description language tool to permit the generation of IPC code and to help emphasise component interfaces and protocols. It seems to me that a lot of the point in having systems that facilitate component-oriented architectures is to make such details explicit, as was indeed emphasised by projects like Spring. Otherwise, everyone might as well be writing stuff for frameworks in the Linux kernel. Anyway, I am sure that there are plenty of people developing for and enhancing L4Re who are content with their situation and what they are able to achieve. But I personally feel that opportunities are being missed to apply these technologies to areas where they would make a real (and, crucially, positive) difference. If anyone else (still reading by this point) is even vaguely interested in general-purpose operating system development on L4Re, it would be nice to hear from you. Paul

4 11

Compatibility of microkernel systems with legacy OSes; was L4Re with GCC 9; Repositories and Roadmaps
by Andrew Warkentin 30 Jan '20

30 Jan '20

On 1/28/20, Martin Decky <martin.decky(a)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(a)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: > > https://gitlab.com/uxrt > > 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.

3 9