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 _______________________________________________ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
