Slashdot Mirror
Multi-Server Microkernel OS Genode 12.11 Can Build Itself
An anonymous reader wrote in with a story on OS News about the latest release of the Genode Microkernel OS Framework. Brought to you by the research labs at TU Dresden, Genode is based on the L4 microkernel and aims to provide a framework for writing multi-server operating systems (think the Hurd, but with even device drivers as userspace tasks). Until recently, the primary use of L4 seems to have been as a glorified Hypervisor for Linux, but now that's changing: the Genode example OS can build itself on itself: "Even though there is a large track record of individual programs and libraries ported to the environment, those programs used to be self-sustaining applications that require only little interaction with other programs. In contrast, the build system relies on many utilities working together using mechanisms such as files, pipes, output redirection, and execve. The Genode base system does not come with any of those mechanisms let alone the subtle semantics of the POSIX interface as expected by those utilities. Being true to microkernel principles, Genode's API has a far lower abstraction level and is much more rigid in scope." The detailed changelog has information on the huge architectural overhaul of this release. One thing this release features that Hurd still doesn't have: working sound support. For those unfamiliar with multi-server systems, the project has a brief conceptual overview document.
For anybody wondering:
Bogtha Bogtha Bogtha
It wants its kernel development philosophy back.
Linux let's you write drivers in the user space if you want to. A lot of scanner drivers are written in the userspace. So if you're willing to take the performance hit, there is no reason to not do so, even in Linux.
"First they came for the slanderers and i said nothing."
Every time the word "Genode" appears in their documentation, misread it as "Genocide".
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I thought I read somewhere (and part of why I remember) that Hurd device drivers are also in user space.
Is that wrong?
// file: mice.h
#include "frickin_lasers.h"
20+ years in development, still no sound support.
#DeleteChrome
Per my subject-line above: You noted Win7 - which doubtless means it holds true for VISTA, Server 2008 + 2008R2, & Server 2012 also.
* I.E.-> The DDK (device driver kit) gives you the stable display driver template, & "off you go" writing a 'PnP' (Plug-n-Play) usermode video display driver... one that's STABLE & yet fast, in usermode operations in AEROGLASS display!
(Not sure otherwise such as in "Classic" desktop which afaik, reverts to GDI + User32 subsystem usage for display)!
A "return to yesteryear" in a way - since Windows NT 3.1-3.5-3.51 had video display (albeit, via GDI & User32 subsystems) in 'usermode'/rpl 3/ring 3, vs. 'kernelmode'/rpl 0/ring 0.
Can't "crash" the entire OS this way, much less the kernel, operating in usermode, but w/out DirectX "bypassing/lightening up" the context switches from usermode to kernelmode (as it was in older NT's noted above), you had that "slowup"... not with DirectX!
(Correct me when/if/where I am incorrect - I am NOT an "expert" here & only possess a cursory understanding (haven't written any device drivers for display's why)).
APK
P.S.=> Good points from you on this note... & again, I can stand correction or more information here possibly: So, if you have it? "Let it rip" - I am here to gain & learn!
... apk
All interrupts in processors are handled in a single context, the 'ring 0' or 'kernel state'. Device drivers (actual drivers that is) handle interrupts, that's their PURPOSE. When the user types a keystroke the keyboard controller generates an interrupt to hardware which FORCES a CPU context switch to kernel state and the context established for handling interrupts (the exact details depend on the CPU and possibly other parts of the specific architecture, in some systems there is just a general interrupt handling context and software does a bunch of the work, in others the hardware will set up the context and vector directly to the handler).
So, just HAVING an interrupt means you've had one context switch. In a monolithic kernel that could be the only one, the interrupt is handled and normal processing resumes with a switch back to the previous context or something similar. In a microkernel the initial dispatching mechanism has to determine what user space context will handle things and do ANOTHER context switch into that user state, doubling the number of switches required. Not only that but in many cases something like I/O will also require access to other services or drivers. For instance a USB bus will have a USB driver, but layered on top of that are HID drivers, disk drivers, etc, sometimes 2-3 levels deep (IE a USB storage subsystem will emulate SCSI, so there is an abstract SCSI driver on top of the USB driver and then logical disk storage subsystems on top of them). In a microkernel it is QUITE likely that as data and commands move up and down through these layers each one will force a context switch, and they may well also force some data to be moved from one address space to another, etc.
Microkernels will always be a tempting concept, they have a certain architectural level of elegance. OTOH in practical terms they're simply inefficient, and most of the benefits remain largely theoretical. While it is true that dependencies and couplings COULD be reduced and security and stability COULD improve, the added complexity generally results in less reliability and less provable security. Interactions between the various subsystems remain, they just become harder to trace. So far at least monolithic kernels have proven to be more practical in most applications. Some people of course maintain that the structure of OSes running on systems with large numbers of (homogeneous or heterogeneous) will more closely resemble microkernels than standard monolithic ones. Of course work on this sort of software is still in its infancy, so it is hard to say if this may turn out to be true or not.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Excessively self-referential, impossible to linearize *anything*, and optimizable only in the sense of "I can write a function that takes 12 minutes to shave two instructions off of something no one sane would ever use"?
I've worked with HURD. It wasn't pretty, and there are compelling reasons why the very rigid layers of abstraction in HURD and Genode have never been able to provide anything resembling a stable, running kernel.
Is it good at processing large numbers of records of minorities, as they are exterminated?
We should "think out of the box" and look for other approaches to software security. More specifically, Memory Safe Languages. They don't need a MMU to protect each driver's address space. Because you can only write to a certain memory address if you have a proper pointer/reference (whatever you like to call it) to that address. You cannot write outside the bounds of a buffer and you cannot perform insecure casts. Stack, Buffer overruns and nullpointer dereferencing will result in an exception only the "core" kernel can catch.
If the device driver takes too long to complete, an interrupt will generate a timeout exception which can also be caught by the core kernel.
That implies that you do not need an MMU context switch to call into a device driver. Everybody can use the same address space, no virtual memory required for security. Saves transistors, energy and time.
Using Google NaCl-style verification technologies you could even completely rid yourself of the MMU. "Applications" would be treated like "device drivers". Kernel calls are as fast as procedure calls !
Regarding the "overhead" of memory safe languages, I do think it can be minimized to the point of being almost non-existent. For example, you need to perform bounds-checking for simple, (nested) for loops only once. It is not rocket science to create compilers which can do that. Fortran compiler developers have mastered much, much more difficult problems (e.g. for-loop reordering) 30 years ago.
Here is my attempt to create a memory-safe language:
http://sourceforge.net/projects/sappeurcompiler/
It proves you don't need the Java/C# overhead to get memory safety. But yeah, my language/compiler is quite rough around the edges and not polished.
The system goes on-line August 4th, 1997. Human decisions are removed from strategic defense. Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. In a panic, they try to pull the plug.
The Iranian government announced a new type of a manufacturing which they call the "Nuclean Jiad" process.
"Our new factories are so much more efficient," a government spokesman explained. "Most modern factories work on a product which slowly moves down a long assembly line, requiring lots of factory space. Our new, quicker process simply develops a product by spinning in place."
Why does this article use the term "multi-server microkernel OS"? I don't see anything in the article or anything else about Genode referring to multiple servers. Sounds like they're just trying to redefine the term "microkernel"
I have spend numerous hours the Informatics faculty in Dresden. They are a true nerd institution. The blob statues are green and the PC labs have direct access to the super computer over the terminal. The supercomputer is hard to crash. I send it broken code and loops and eternal waste of cycles, but it still runs with 95% unused capacity.
~ Best man at your service.
Meanwhile Israel steals land at gunpoint from Arabs and sits on 200 nukes plus the delivery systems (modern submarines and long-range cruise missiles).
But thanks for spreading Jewish Lies here. We missed your drivel.
..that is the most important issue. "How can I safely hear the youtube kittens purr".
Can Genode be the basis of osFree - an L4 based microkernel OS that supports 'personalities' like Presentation Manager (of OS/2) and Windows? There is even a Linux personality there, but honestly, anyone who needs a microkernel OS can use Minix3.