On 9/14/18, Paul Boddie <p...@boddie.org.uk> wrote: > > But one of the lessons from the phenomenon of Java is that people don't like > > to be told to rewrite all their stuff in a particular language, and although > > you can try and make the runtime language-neutral, some languages end up > being > more equal than others. >
Yeah, that would be the biggest thing that limits the appeal of language-based OSes. > > It is interesting to consider Nemesis, which evolved into Xen, in this > regard: > > https://en.wikipedia.org/wiki/Nemesis_(operating_system) > > One of the goals was to support POSIX applications, and it was apparently a > > usable system in its day, maybe still is. > I knew Nemesis and Xen were from the same group at Cambridge but I didn't know that there was much of a connection other than both being somewhat exokernel-ish. > > It is also interesting to see the UX/RT label given the heritage of Unix > systems: > > https://en.wikipedia.org/wiki/Multi-Environment_Real-Time > I'm well aware of MERT/Unix-RTR, although UX/RT won't really be similar beyond being a microkernel-based Unix-like RTOS. It will have a general structure like that of QNX and a VFS model similar to that of Plan 9 (the name is kind of an indirect reference to QNX's name originally being derived from "Quick uNiX"). > > In the L4 microkernel-related materials I have seen, nobody seems to mention > > this work or even the foundational influences on it. Indeed, one set of > slides > calls the Mach microkernel "The mother of all microkernels", later to > discuss > IBM Workplace OS and to note that "OS personalities did not work". > Presumably > such remarks are made in that specific context given that DMERT apparently > supported multiple personalities (Unix-RTR and RSX-11). > Yeah, a lot of people seem to think that Mach was the first microkernel, but nothing could be further from the truth. QNX predates Mach by several years, and it has always been somewhat similar to L3/L4. I think Mach was the single worst thing to happen to microkernels. It completely destroyed the reputation of microkernels with its slow, heavyweight IPC. I think it may have hurt the reputation of OS research in general as well, creating more of a divide between research and mainstream OSes. I wonder if microkernels would be widespread on an alternate timeline where QNX had somehow had significant influence on OS research as soon as it came out (Mach may not have been written, or may have been QNX-like instead). Another thing that has hurt performance on microkernel OSes that I haven't heard discussed is component-level versus subsystem-level modularization. It seems like most microkernel OSes go for component-level modularization everywhere (e.g. separate processes for disk device driver and disk filesystem, or process manager and VFS). The problem with component-level modularization is that it multiplies the number of context switches for a system call in many cases, and often provides little benefit to security or stability (e.g. both a disk device driver and disk filesystem are both dealing with the exact same data, just on different levels, and compromising either would basically be equivalent; similarly, an OS with restartable servers should allow recovery from either a disk device driver or disk filesystem crash, so splitting them up doesn't provide any benefit there). UX/RT will take a similar approach to QNX and will use subsystem-level modularization in many places (e.g. there will be a disk server incorporating both device drivers and filesystems, with support for multiple instances; similarly, the memory manager, VFS, and certain in-memory special filesystems will all be part of a single root server). > > Who is to say that an incompatible system does not have "practical > real-world > usage", though? I agree that compatibility would be helpful, and there are > plenty of systems that exist only through the perseverence of their > creators, > only to fade away at some point, partly due to a lack of interest and > difficulties integrating mainstream software. > Yes, an incompatible OS may be able to achieve success in some niches, but even that will be made more difficult by the incompatibility. > > Personally, I am also interested in what it would take to develop a vaguely > > standard multiserver system, albeit leveraging L4 technologies. A while > back, > people tried to get the Hurd working on L4 (Pistachio, I think), and I think > > there is potential to get something like that going on Fiasco.OC, > particularly > since the lack of capability support was supposedly the reason why the > Hurd-L4 > work was abandoned. > I've never really been a fan of Hurd. It gets its VFS model backwards by requiring you to bind servers to disk files. It causes major problems with determining the context that passive translators should be started in, and it also requires the disk filesystem to support storing the translator as file metadata. UX/RT will use pure in-memory mounts like QNX and Plan 9, and the contexts in which demand-started servers are run will be explicitly specified by the init system configuration, rather than inheriting them from another server (no need for elaborate process persistence schemes to resolve the context problem like have been discussed for Hurd). On 9/14/18, John <john.r.mo...@gmail.com> wrote: > > The Kernel-CLR runtime is basically a fancy privileged service loader, and > doesn't run userspace applications. Basically, if you can load a driver, > you can get Kernel-CLR to process arbitrary input. > Then you effectively have a monolithic kernel, not a microkernel, if you have a kernel module loader and drivers run in the kernel's context rather than as normal processes. The whole point of a microkernel is to make an OS that's extensible through normal processes. A kernel module loader greatly increases the attack surface, even if you are using language features to protect kernel modules from one another (as a few people here have said, hardware-based protection is generally more robust than language-based protection). > > I've long considered the prospect of reverse paravirtualization, whereby > you put a paravirtualizing driver inside an HVM OS and pass the OS direct > IO mapping to a hardware device. The PV driver then lets the hypervisor > send it requests, and it arbitrates with the local operating system. In > other words: the hypervisor is paravirtualized on the guest OS (reverse > paravirtualization). This would enable using Linux as a mega-driver, while > L4Mx/Linux running a Linux kernel paravirtualized could do the opposite. > This is a little bit like what I was planning to do on UX/RT, although I was planning to use the LKL project <https://github.com/lkl/linux>, which turns the Linux kernel into a library (UX/RT will have good support for virtualization, but it won't really focus on internal full-system virtualization, and will focus on containers/overlays more as far as built-in virtualization goes; it will probably also eventually include a separate Type 1 VMM that will mostly be intended for desktops and servers rather than embedded systems). _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers