A new kernel for an OS caled LSE/OS was developed by a french research laboratory: Epita System Laboratory. This laboratory is specialized in low-level system programming.For more than one year this laboratory has been developing an extremely stable nanokernel with specific features that place it in a very special class of systems. Read on for more. Update: English version here.
The LSE/OS developers claim that this kernel has some interesting advantages on modern systems such as: Linux, *BSD, etc.
Abandoning the monolithic model, this kernel offers a very simple development interface.
The main goal of this system was to never crash. For this reason, the core designers decided to adopt a nanokernel model because it permits to move the drivers and services code out of the core code. These services becoming “privilegied” processes. With this model, an error can occurs in a driver without crashing the system that is impossible is a monolithic model such as linux.
This kernel was designed to be modular. This feature implies that the kernel code is finally very light and the source of bugs are now limited to the very small core code.
This system is now open source but needs help to evolve. Indeed, some programs and drivers has to be ported or developed. Also some specific applications have to be developed to exploit the LSE/OS interface and to demonstrate the rapidity and flexibility of this kernel.
Please refer to the site of the laboratory for more details on this project: www.lse.epita.fr
Ok, so how is this different from a true microkernel? It’s my understanding that in a true microkernel drivers are not in kernelspace too.
The site is way too slow to do any further investigation.
…so are they saying that Linux crashes often? :/ If so, how can Linus improve the kernel?
I don’t know much about it either. I did find a paper describing some of the design concepts of KeyKOS (another nanokernel) and covering some of the basic design concepts of nano’s.
http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html
A nano may also be considered a microkernel is much the same way a square is also a rectangle.
…No, they never said anything like that. They simply said that their goal is to create a kernel that will never crash.
“…so are they saying that Linux crashes often? :/ If so, how can Linus improve the kernel?”
where did they say that. dont bring linux to this discussion.
even as a linux user i dont find that necessary
Do not know why they did not provide a direct link (stupid PR translation ?), but here it is, this page is mostly in english.
http://www.lse.epita.fr/lseos.php
Even with the device drivers out of the inner kernel, that doesn’t entirely prevent the computer from crashing. I’m pretty certain the an errant driver could still send the wrong commands to devices, ones that could, for example, cause the machine to reboot or the chipset to lock up in some odd mode. The would still get the same goal in the end.
Hi,
I’m one of the conceptors of LSE/OS and I’m reading your comments. Our website is slow but it is hosted behind a simple ADSL link but I think we are going to move repository to our school link which is much faster.
Due to the evident interest the project has suscited, we are probably going to modify our approach to be much more international soon.
Concerning the technology itself, I’ve seen a discussion about driver stability. There will never be a full stability due to hardware BUT in LSE/OS code examination of vendor software has to be checked to only 1% of the code (the bottom halves which may indeed hang the cpu).
If the driver crashes in a normal thread it won’t hang the system contrarily to Linux.
We are seeking for help in developing this fantastic (to our sense) potential.
And momentum that it would be tough for even a superior os to take over the lead.
I like microkernels,even though they are slightly slower , for tradeoff in stability.
Anyone hear of exokernels ?
I like microkernels,even though they are slightly slower
The speed-loss is neglicable when using today’s hardware– Try QNX on a modern day computer and you will experience NO loss of speed or responsiveness.
The muK vs. monolithic debate reached its peak in the early nineties– computers are much, much faster these days, making up for the speed-loss when comparing a muK to a monolithic kernel.
Drivers outside the core!!!!
Sounds a little like Dos to me…..
Yet i know that this is much, much more advanced.
Drivers outside the core!!!!
Standard practice when doing a muK (or nanokernel? Ain’t that the same?). Even Windows NT/2000/XP/Server 2003 started started life as a muK.
I know!!!!
It was just a little thought U see!!! 😀
lol.
Imagine if this was posted in Slashdot.
Poor french site would go down for hours.
The good news is – they never submit my stories
nano-kernels are cool
they are mitochondria-compatible.
(please don’t bring biology into this conversation)
Very informative slides – I like it.
It would be kind if you could put the slides in a single concentrated format possibly through .pdf files. It is a bit annoying to read slides like this.
Even if you give proper names to the files, it will make me happy.
Can someone explain me the difference between nanokernel and exokernel?
I especially like the concept of eliminating the difference between managing memory and hard disk. Fundamentally, they are both storage devices and should be managed centrally and similarly, theoretically speaking. The concept of unlimited storage capacity also moved me.
If this project can survive 7 years, it will go places. I am happy they are addressing some of the problems that plague many of todays’ operating systems. Limited storage capacity, ugly threading, ugly hacks for parallelism, unreliability, closed development environments and so on.
a nanokernel and a micro kernel? does a nano kernel have even less functionality than a microkernel?
Look at the Chorous microkernel that have a (IMHO) clean storage model.
Are you referring to the Chorus kernel that was developed by SUN Microsystems, but will be replaced at a later date with a ultra-slim down version of Solaris? IIRC, the source code is now available on it via SUNs experimental projects website.
So this is something like QNX? If they keep it “unix-compatible” that means that this project could have much potential.
what are the differences between the L4 kernels and LSE/OS?
They have still very different properties, such as access time (disk is about 1 million time slower than RAM), persistency, size.
It isn’t the first time this is tried, I think that the (dead) EROS also tried to do this.
One thing that I find funny is the dependency on x86, especially with the usage of Intel CPU-rings, it may makes LSE/OS difficult to port to other CPU (RISC have usually only two levels).
In general, some kernels like mach blemished the term microkernel, and forced other, leaner kernels to take on the term nano-kernel. Basically the same concept, though.
Exokernels are far more extreme. They typically aim to provide no high level interfaces to hardware, and tend (from what I’ve seen) to aim to run below another OS, and mainly deal with resource sharing. Theoretically, some intend to run an exokernel with say Linux, and FreeBSD running atop of them, for example.
Nano kernels are 1000 times smaller than micro-kernels wich are 1000000 times smaller than monolithic kernels. At least thats what they told me at the Academy.
Seeing QNX having nearly nothing into its micro kernel, then LSE/OS having just a little less into a then-called nano kernel, i wonder what can be removed from a nano kernel 🙂
What would you put into a pico kernel ?
And: why compare to linux everywhere in your white paper ?
The linux structure seems for me a very old approach for os, and comparing your new os with a so old one (and so different) does not mean anything good for you.
In fact any real time micro kernel could say “rest in peace” to linux.
Why do not compare LSE/OS with good micro kernels ?
TOTO 3D wrote:
> i wonder what can be removed from a nano kernel 🙂
> What would you put into a pico kernel ?
Well idunno about the naming scheme used for this, but O3ONE runs very little code in ring-0 if useing x86 hardware:
“The ‘kernel’ actually runs mostly in exec (level 1) mode. Only the default exception handler runs in true kernel mode, and very small ‘int’ instruction handlers to access the control registers.”
From: http://www.o3one.org/ ( – under “x86 stuff”. )
If this OS came out with full POSIX emulation and if possible with a Linux API compatibility layer and they ported the equivalent of a KNOPPIX boot CD for testing purposes (NOTE: Lots of drivers to port and test!) then they may stand a chance.
Till then… Have fun!
Sergio
No need to rain on their parade. If they want to work on something cool, let them do it.
By renoX wrote:
> It isn’t the first time this is tried, I think that the (dead) EROS also tried to do this.
Yes utterly kewl stuff. And i don’t think it’s dead, developing at slow pace maybe – Committed at: 2004-07-26[0]
> One thing that I find funny is the dependency on x86, especially with the usage of Intel CPU-rings,
That part makes me think “nanokernel” is something like a MLS (Multi Level Security) scheme, such as used in Orange Book compliant systems like GEMSOS[1] – Only i don’t know of any OSS OS implementing something like that, although i read about the TCX research project[3].
However LSE/OS seems to be striving for POSIX conformance too (which is a good thing, if they want it to be used as general-purpose OS) and in that sense might be better compared to VSTa[2] or some such.
> it may makes LSE/OS difficult to port to other CPU (RISC have usually only two levels).
Maybe so. To me it would seem some what easier to make this run as a “normal” kernel on that kind of hardware, then it would be the other way around. Ie: cutting some Unix (like: Linux or *BSD) in parts for processors that support multiple rings.
[0]http://www.opencm.org/opencm/~/PUBLIC/EROS/DEV/eros/top/src
[1]http://www.geminisecure.com/
[2]http://www.vsta.org:8080/
[3]http://www.google.nl/search?q=TCX+Trusted+Computing+Exemplar
>Maybe so. To me it would seem some what easier to make this >run as a “normal” kernel on that kind of hardware, then it >would be the other way around. Ie: cutting some Unix (like: >Linux or *BSD) in parts for processors that support multiple >rings.
No problem using only two rings: the drivers interrupt handlers would be ring0.
X86 macro instructions (lcall, iret) are composed of smallest instruction so why not rewriting them for RISC targets ?
A tarball is now available on the LSEOS website containing
a small UN*X emulation based upon an old version of BSD.
It works ! The major problem was to emulate file descriptors but we found a good solution for that and we are much FASTER !!!
Let’s have a look at the fork(2) and execve(2) implementation.
here is an english version
http://etudiant.epita.fr/~lse/
It’s great to hear that the principals in this project are keeping up with the comments posted here. One of the biggest questions I had about LSEOS, and one that was not substantively answered in the posted whitepaper, was what is its relation to other microkernel research that has already been conducted? The bibilography was somewhat sparse, yet I know that there has been a substantive amount of research done on these types of systems.
If the architects have some time to explain how LSEOS relates to the larger body of micro and nano kernel research, it would be quite interesting. Specifically, I’m curious which design principles of existing research were included and why, and also, what designs are different and for what reasons these unique designs were adopted? I didn’t get a really clear sense of the underlying system architecture from the posted materials. It may be that most of the interesting ones are in French, and haven’t been translated to English yet, but I’m still curious.
We admit LSE/OS is quite an intuitive model but bibliographical research is I thinks compensated by experience regarding kernel programming.
A team of university researchers is going to introduce methodology and various proofs in order to reassure people.
We refer to some previous work like aborted DDK (Driver Development Kit which wanted to uniformize driver development among different architectures) or we have kind of BSD approach in coding style but we think we are quite distant from them.
We refer mostly to the Intel engineering work concerning hardware extensions (hardware context switch and so on) to their processors (imagining they area quite right concerning the future of computing).
The main idea (not so original we admit) instead of having a central kernel which redistribute syscalls to drivers is that drivers directly calls other drivers (e.g the timer driver uses the pic driver to acknowledge the interrupt).
At this point we make a real difference between a server (a Unix daemon) and a service (a hardware taskgate which could be a driver or a pseudo-driver). In LSE/OS we have got both: daemons are in fact simple schedulable tasks which wait for signals).
There is another real important point is that we use POSIX signals to do everything asynchronous, e.g read is neither more read(2) the syscall but read(3) a simple function which wait for the SIGIO signal to perform the asynchronous action (we should have made things different but it is a great choice to have everything natively asynchronous). Anyway we haven’t invented the SIGIO signal.
We must say we arean’t distinct from BSD signal.h and errno.h because we wanted to be fully BSD compatible.
Contrarily to what have been said here, we are fully ‘POSIX’.
Our team is just a team which is used to Linux and BSD kernel programming and wanted to go further.