On Wednesday 22. January 2020 13.47.15 Matthias Lange wrote:

Hi Paul,

[...]

The version on github supports GCC 9.

I guess I will look at that when I eventually need to use GCC 9 again.

[...]

The code on github is the development version of L4Re. As you rightly pointed out the snapshots are considered more stable (API wise etc.). Usually you can mix projects from github with projects from the snapshot.

I think the problem would be in organising the different repositories. The convenient thing about the Subversion arrangement, perhaps facilitated by the repomgr tool, was the ability to obtain a set of compatible components. I see that the ham tool attempts to do the same thing for the 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).

That usually is what the L4Re snapshots are for. Or you can download ZIP archives of our projects from github.

This is what I have been doing for other GitHub-based projects, but it would probably defeat the automation, unless the ham tool can be told to only get snapshots. Another thing that has been partly successful is to tell Git to use a depth of one changeset when cloning, which maybe ham can be modified to do, although I do still encounter "index pack" failures even then.

[...]

You are right that no public roadmap for L4Re exists today. But that doesn't mean there isn't any ;). Currently L4Re is not targeted to become a general purpose OS.

Was TUDOS meant to be general-purpose in some way? I don't have high expectations about what is meant by this term, by the way. What I mean is something that would run on a device, support fairly standard input and output devices (keyboards, pointers and screens, for instance), would be able to access storage holding a proper filesystem, and would support the execution of programs, shells, and so on.

I would also disagree that there is no L4Re development at all. A fair amount of development is about stability and robustness. For example we are still dealing with the fallout of Meltdown and Spectre and the following hardware vulnerabilities.

I guess I am just saying that I don't see much sign of development.

[...]

Yes, documentation could always be better. In fact we (Kernkonzept) is searching for a documentation engineer for months. In the end it is about priorities and unfortunately documentation is currently not our top priority.

Documentation is nobody's top priority. This is how we end up with the Linux kernel, funded by multi-billion-dollar corporations, but with laughable documentation and a culture of asking around on mailing lists and IRC channels to find out what somebody was thinking once upon a time in an office at IBM, Google or wherever.

[...]

...

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.

Would you mind sharing the use-cases you have in mind?

Well, alongside the rather simple definition of general-purpose computing, I think that there is a demand for simpler, more transparent systems for both deployment and to serve as a more effective environment for development.

The former use-case is probably familiar to you and others who support L4Re and similar systems commercially, although I could note that beyond the usual crowd of people who - for example - get excited about seL4 because one of the letters stands for "security", there does seem to be an increasing awareness of the ingredients of computing systems, what can be audited and what is opaque. Packing a Linux kernel full of every last driver "just in case" and then layering distributions on top, even though hardware gets faster and can support it all, just isn't sustainable in a number of different respects.

The latter use-case is perhaps more contentious. It might seem more productive to work in an existing computing environment and to develop for other systems using tools like qemu, or to just shake the box that is the Linux kernel and hope that the pieces eventually fit together, but having spent quite some time recently messing around with driver support for the CI20 in modern Linux kernels, I can easily see that a minimal low-level environment could be useful in prototyping device drivers and developing hardware support productively.

Such claims might contradict the traditional thinking about such matters. One of the things people tend to say about microkernel-based systems is that they will struggle to compete with Linux because of all the drivers already written for Linux, and the thinking then goes that maybe it is worth borrowing drivers from Linux. But surely one of the strengths of microkernel-based systems is that there is a flexibility permitted in the design of such systems that should make driver development easier. (I also wonder how much people have looked at what goes into the average Linux driver.)

It seems to me that things that might seem mundane to you and your colleagues would be worthwhile improvements to the experiences of other people if delivered to them. People are often exposed to new ideas and like the sound of them, and over the years there have been plenty of interesting systems which could have been adopted had the barrier to entry been lower. In some cases, exploring these ideas has involved buying into the way some fairly esoteric systems work. In others, the ideas have been clumsily exported to existing systems.

A relatively minimal system could permit the prototyping and exploration of such ideas without imposing too much esoteric baggage. It seems to me that L4Re, suitably enhanced, could provide such a foundation. It wouldn't be exciting for the security crowd (or wherever all the money is going this season) or make for good academic publications, but it might be useful nevertheless.

Anyway, I think you probably understand what I am trying to say.

Paul

On Thursday 23. January 2020 12.44.29 Martin Decky wrote:

Sorry for playing Captain Obvious here, but there are other microkernel-based operating systems (both inside and outside the happy L4 family :)) that might be closer to achieving this goal of suitability for general-purpose computing.

A curated list can be found at http://www.microkernel.info/

Well, I am aware of several of them, of course. Maybe my memory is failing me, but I am pretty sure I mentioned the Hurd in a recent message, and previous messages will have mentioned Minix 3 as well. Those two are probably the ones that most Free Software developers would recognise and investigate further. I have previously looked at Genode, HelenOS and various parts of seL4, mostly to see what kind of architecture they employ for certain aspects of the system.

My motivation for using L4Re to begin with was that it works on the MIPS architecture. Indeed, using it on the MIPS Creator CI20 was the entry point for using it on other related devices and for more general investigations. I did look into a number of different operating systems - microkernel and otherwise - as part of my familiarisation with the MIPS architecture, experimentation with bare-metal code, and gaining confidence in deploying low- level software. (Of course, I was already using these devices with Linux, in case anyone feels the need to make me aware of its existence as well.)

The primary considerations for me when adopting software include things like whether...

* I have a chance of running it on hardware I actually have * It can be used for practical things * It is documented beyond academic papers * Obtaining and deploying the software is relatively convenient

Where your interests and mine may diverge is that I am not particularly interested in whatever the current trends are with regard to microkernel design, even though some of these design elements may be useful and worth pursuing. Most of the "next big thing" microkernels that get announced tend to get abandoned in short order (often for the next "next big thing"), so I would rather focus on projects that have actually been around for a while.

Naturally, this might mean having to deal with an imperfect collection of mature software, hence my complaints about certain aspects of L4Re, although perhaps my most significant reservation about working with L4Re is that there doesn't seem to be any kind of community around it. Maybe if other independent developers were using it, there would be an exchange of ideas that would be beneficial to everyone concerned.

If you have any concrete suggestions of systems other than L4Re that provide a decent, if basic, level of support for running user space programs written in mature languages, that work on the MIPS architecture, and that have not already laid down a rigidly prescriptive system architecture that would make experimentation awkward, I would obviously like to hear them.

Paul

On Thursday 23. January 2020 16.03.55 Martin Decky wrote:

...

If you have any concrete suggestions of systems other than L4Re that provide a decent, if basic, level of support for running user space programs written in mature languages, that work on the MIPS architecture, and that have not already laid down a rigidly prescriptive system architecture that would make experimentation awkward, I would obviously like to hear them.

HelenOS offers decent (but basic) support for running user space programs written in C, C++ and to a lesser degree in Python, Lua and Java. There is a feature branch with Go support.

It sounds like it might be worth examining more closely.

Our MIPS support is limited to the ancient Malta development board and emulators, but it could be extended to platforms such as Ben NanoNote and CI20 quite easily (actually, both have been our GSoC project ideas for several years).

I doubt that you will have read (or wanted to read, at least in full) the articles I wrote about extending the MIPS support in L4Re and Fiasco.OC to the Ben NanoNote [1], but is there any relatively in-depth documentation describing approaches to supporting new hardware in HelenOS?

I am too biased to judge whether HelenOS' architecture is rigidly prescriptive, but we are definitively all about experimentation :)

That is good to hear, at least. These days, many people appear to be rather jaded about applying new ideas or re-applying old ones to operating systems. I completely understand that all the money is elsewhere (in "cyber", apparently), but it seems to me that there is a wealth of interesting work that could fairly readily be re-evaluated and revived for the benefit of the humble end-user.

I would guess that the MIPS support is the most restrictive requirement from your set that probably rules out most of other potential candidates.

I think that it is pretty inexcusable for a lot of new systems not to be portable. While there may be some useful hardware features supported by specific silicon vendors, and while some systems may leverage such features to demonstrate a particular kind of solution, there is a real risk of such systems ending up in niches, particularly if the vendors change direction and switch technologies or if those features are flawed, need refinement, and all the usual pitfalls involved in relying on silicon vendors.

But there might be a new mature real-time microkernel-based OS with MIPS support released as open source soon. Let's watch the HIPPEROS talk at FOSDEM 2020 and let's keep our fingers crossed.

It will be interesting to hear what comes of this. I guess that anyone anticipating success with their own proprietary microkernel technology should take note of the lessons that will presumably be given by this talk.

Anyway, thanks for the recommendation, and if there is anything in particular that you feel a broader audience should know about HelenOS, please feel free to weigh in. My focus has been on L4Re specifically, but there are always possibilities to learn from what other systems do.

Paul

[1] https://blogs.fsfe.org/pboddie/?p=2147

I think the only way a microkernel OS is going to have anything remotely resembling broad success is if is natively Linux-compatible at both the application and driver level. Few people are going to switch to an OS with limited hardware and application support even if it is more secure and/or more flexible architecturally. Seems like I'm one of the few who sees it that way though. I'm not aware of any similar projects to my own (there are a few natively Unix-like microkernel OSes but none have Linux compatibility AFAIK).

On 1/22/20, Paul Boddie paul@boddie.org.uk wrote:

Such claims might contradict the traditional thinking about such matters. One of the things people tend to say about microkernel-based systems is that they will struggle to compete with Linux because of all the drivers already written for Linux, and the thinking then goes that maybe it is worth borrowing drivers from Linux. But surely one of the strengths of microkernel-based systems is

that there is a flexibility permitted in the design of such systems that should make driver development easier. (I also wonder how much people have looked at what goes into the average Linux driver.)

There is already a project that makes the Linux kernel into a library, which should mean that it will be relatively easy for a microkernel OS to borrow drivers from Linux, as long as the OS sticks to a process-per-subsystem-instance architecture rather than separating subsystems into processes vertically. It doesn't yet support physical device drivers, but it should be possible to add it (which is what I'm planning to do).

On Monday 27. January 2020 18.28.05 Andrew Warkentin wrote:

I think the only way a microkernel OS is going to have anything remotely resembling broad success is if is natively Linux-compatible at both the application and driver level.

There will be people who disagree with that statement based on what you define "OS" and "success" to be. For instance, it has been noted that large numbers of Intel CPUs run Minix 3 on the management core [*]. Some people would regard that as a success, although I am not so sure I would.

[*] http://blog.ptsecurity.com/2017/08/disabling-intel-me.html

Few people are going to switch to an OS with limited hardware and application support even if it is more secure and/or more flexible architecturally. Seems like I'm one of the few who sees it that way though.

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.

If the limited hardware and applications support is pretty much baked into a system then I think it is a bad strategy to pursue. However, if the system is portable and if the environment is there for developing drivers and applications then I think the situation is rather different. It should be remembered that Linux is in a state of constant churn: drivers stop working, systems get refactored, people get told to keep up, rework and resubmit. And the user space tends to track the kernel, meaning that older kernels that happened to support particular hardware configurations cannot be used with modern distributions.

The idea that Linux has everything covered is perhaps mostly true: the broad support for hardware has motivated its use where other systems have seemed less plausible (for example, Android making use of Linux instead one of the BSDs, which was a choice made by at least one preceding project of that nature). But it isn't necessarily something that is delivered completely for free, nor does it absolve anyone of any effort: the catalogue of vendor kernels, non-upstreamed drivers and obsolete devices is testament to that.

I'm not aware of any similar projects to my own (there are a few natively Unix-like microkernel OSes but none have Linux compatibility AFAIK).

Your project being this one:

https://gitlab.com/uxrt

Is there a summary of it anywhere?

[...]

...

that there is a flexibility permitted in the design of such systems that should make driver development easier. (I also wonder how much people have looked at what goes into the average Linux driver.)

There is already a project that makes the Linux kernel into a library, which should mean that it will be relatively easy for a microkernel OS to borrow drivers from Linux, as long as the OS sticks to a process-per-subsystem-instance architecture rather than separating subsystems into processes vertically. It doesn't yet support physical device drivers, but it should be possible to add it (which is what I'm planning to do).

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.

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.

Paul