C Library Experiments (was Re: L4Re with GCC 9; Repositories and Roadmaps)
On Wednesday 22. January 2020 01.48.17 Paul Boddie wrote: > > 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. Well, I started writing up some details of this particular experiment, publishing them at the following location: http://projects.boddie.org.uk/L4Re-Notes/CLibraryExperiment/ It probably doesn't noticeably inform those people who have done such work before for L4Re, or anyone else who might be doing such work now, but I suppose it might still be of casual interest more generally. There is also the matter of the interface description language and its tool, which is also rather an unfinished product, and when time permits I aim to publish some information about that as well. Paul ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Re with GCC 9; Repositories and Roadmaps
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 ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Re with GCC 9; Repositories and Roadmaps
Dear Andrew, > 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). 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. 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. There have been several projects targeting componentization/libification of the Linux kernel over the years. If the one you have mentioned won't be short-lived and eventually gets officially supported by the Linux community (like the rump kernel for NetBSD) then it will be certainly a tremendous help for all microkernel projects. Best regards Martin Decky ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Re with GCC 9; Repositories and Roadmaps
Dear Paul, > 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] I've skimmed through some of your texts quickly. It is definitively an interesting reading and your observations might be certainly helpful for porting any OS to the NanoNote. Thanks! > but is there any relatively in-depth documentation describing > approaches to supporting new hardware in HelenOS? There is a wiki page about writing HelenOS device drivers [1]. Regarding porting of HelenOS to a new platform, the best source of inspiration and guidance are the master theses that have concerned with similar assignments: UltraSPARC III, IV, T1, T2 [2], SPARC V9 [3]. In the code base of HelenOS, there is also this "abstract 32bit little endian architecture" that is a good starting point for supporting a completely new architecture (instead of scavenging an existing architecture support). [1] http://www.helenos.org/wiki/DeviceDrivers [2] http://www.helenos.org/doc/theses/pr-thesis.pdf [3] http://www.helenos.org/doc/theses/jj-thesis.pdf > I think that it is pretty inexcusable for a lot of new systems not to be > portable. I agree completely. Portability has always been one of the primary design guidelines of HelenOS. > 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. Well, we have a nice web site with resources (but the documentation can always be better :)) and I believe the source code is well-commented. We have a welcoming community on the mailing list and on the IRC channel. If I should mention one URL that I would suggest as a starting point, then this is it: http://www.helenos.org/wiki/FAQ Best regards Martin Decky ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Re with GCC 9; Repositories and Roadmaps
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 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). ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Re with GCC 9; Repositories and Roadmaps
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 ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Re with GCC 9; Repositories and Roadmaps
Dear Paul, thanks for your email. I do not intend to steal the discussion here, this is an L4 mailing list after all, but let me respond very briefly. > 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. 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 am too biased to judge whether HelenOS' architecture is rigidly prescriptive, but we are definitively all about experimentation :) I would guess that the MIPS support is the most restrictive requirement from your set that probably rules out most of other potential candidates. 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. Best regards Martin Decky ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Re with GCC 9; Repositories and Roadmaps
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 ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Re with GCC 9; Repositories and Roadmaps
Dear all, > 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. 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/ Best regards Martin Decky ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Re with GCC 9; Repositories and Roadmaps
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
Re: L4Re with GCC 9; Repositories and Roadmaps
Hi Paul, On [22-01-2020 01:48], Paul Boddie wrote: > 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. The version on github supports GCC 9. > = 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. 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. > 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). That usually is what the L4Re snapshots are for. Or you can download ZIP archives of our projects from github. > = 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.) You are right that no public roadmap for L4Re exists today. But
