info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
A new approach of designing a microkernel based OS
11 views
Skip to first unread message
simon3....@gmail.com
Oct 20, 2014, 5:05:04 AM10/20/14
to
I know, that this is the Mach Newsgroup, but i didn't find a L4 related Newsgroup.
I'd like to present an approach for Microkernel OSs. I'm not skilled in compiling Microkernels and get them to run nor am I familiar with the Mach or L4 APIs. They're just too complicated to me.
The fictional OS, I made a presentation about, is based on L4, however, it could be implemented on Mach too.
https://speakerdeck.com/maxymania/the-fictional-tetris-os
The problem of regular Microkernel OS designs and approaches is
From http://linuxfinances.info/info/microkernel.html
> Unix's syscalls all are synchronous. That makes them a bad target
> for a microkernel, and the primary reason why Mach and Minix are
> so bad - they want to emulate Unix on top of a microkernel. Don't do that.
Regular Microkernel OSs are composed of servers. Every server implements an part of the System API available for User Programs (like webbrowser, mailserver, etc.) or as an internal subsystem such as NIC devices or Audio.
The communication is usually an IPC protocol, that is synchronous and use stuff generated by stub-generators such as IDL4 (L4ka::Pistachio) or MIG (GNU Hurd).
It sucks, it's error prone and the RPC stubs are not designed to deal with malicious messages, or those wich are not expected to receive at the given time (IPC-Jamming).
The (fictional) TetrisOS solves this with a different approach:
* Dont design an API stub.
* Don't introduce a Personalty server or servers that implement APIs (like the Unix syscalls, BSD sockets, STREAMS, OpenGL and so on).
* Design an common protocol for all Programms to speak with each other.
Ion - The protocol family for IPC on Tetris. Remember, it doesn't exist yet.
The Ion IPC protocol has the following sub protocols:
* Ion - Stream: A full-duplex stream protocol like Unix Domain Sockets or TCP
* Ion - Datagram: A datagram protocol like UDP, but locally.
* Ion - Directory: A protocol for Managing Directorys such as Filesystems
* Ion - Random Access Object: A protocol for accessing files in a random access way
* Ion - Resource Sharing: A protocol for allocating Memory
* Ion - Metagram: For everything else
Ion-Metagram is as Ion-Datagram workalike, except, that it intented for Metadata such as Process-IDs, RPC-like stuff, Configuration, Connection-Setup.
Metagram specifies a special, self-describing Data-Structure format.
Ion-Datagram is rather a pass-through protocol. An example use case is the exchange of Ethernet-Packets between the TCP/IP-Stack and the Network driver.
I'd like to present an approach for Microkernel OSs. I'm not skilled in compiling Microkernels and get them to run nor am I familiar with the Mach or L4 APIs. They're just too complicated to me.
The fictional OS, I made a presentation about, is based on L4, however, it could be implemented on Mach too.
https://speakerdeck.com/maxymania/the-fictional-tetris-os
The problem of regular Microkernel OS designs and approaches is
From http://linuxfinances.info/info/microkernel.html
> Unix's syscalls all are synchronous. That makes them a bad target
> for a microkernel, and the primary reason why Mach and Minix are
> so bad - they want to emulate Unix on top of a microkernel. Don't do that.
Regular Microkernel OSs are composed of servers. Every server implements an part of the System API available for User Programs (like webbrowser, mailserver, etc.) or as an internal subsystem such as NIC devices or Audio.
The communication is usually an IPC protocol, that is synchronous and use stuff generated by stub-generators such as IDL4 (L4ka::Pistachio) or MIG (GNU Hurd).
It sucks, it's error prone and the RPC stubs are not designed to deal with malicious messages, or those wich are not expected to receive at the given time (IPC-Jamming).
The (fictional) TetrisOS solves this with a different approach:
* Dont design an API stub.
* Don't introduce a Personalty server or servers that implement APIs (like the Unix syscalls, BSD sockets, STREAMS, OpenGL and so on).
* Design an common protocol for all Programms to speak with each other.
Ion - The protocol family for IPC on Tetris. Remember, it doesn't exist yet.
The Ion IPC protocol has the following sub protocols:
* Ion - Stream: A full-duplex stream protocol like Unix Domain Sockets or TCP
* Ion - Datagram: A datagram protocol like UDP, but locally.
* Ion - Directory: A protocol for Managing Directorys such as Filesystems
* Ion - Random Access Object: A protocol for accessing files in a random access way
* Ion - Resource Sharing: A protocol for allocating Memory
* Ion - Metagram: For everything else
Ion-Metagram is as Ion-Datagram workalike, except, that it intented for Metadata such as Process-IDs, RPC-like stuff, Configuration, Connection-Setup.
Metagram specifies a special, self-describing Data-Structure format.
Ion-Datagram is rather a pass-through protocol. An example use case is the exchange of Ethernet-Packets between the TCP/IP-Stack and the Network driver.
0 new messages