From 696be5d1f72a9e666d3fa1cd1e2ebddfce67e444 Mon Sep 17 00:00:00 2001 From: Alex Auvolat Date: Sun, 30 Nov 2014 17:21:50 +0100 Subject: Add details on NARP OS --- doc/narp.tm | 267 +++++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 182 insertions(+), 85 deletions(-) (limited to 'doc') diff --git a/doc/narp.tm b/doc/narp.tm index 30450f3..8639045 100644 --- a/doc/narp.tm +++ b/doc/narp.tm @@ -707,9 +707,6 @@ implement repetition in the case where the message hasn't been acknowledge? ... - Reserved message IDs : > and - >. - >> @@ -751,45 +748,19 @@ TODO : request account creation, manage user groups and ACLs, ... - - - Client messages [50,100) ; server messages [10050,10100). TODO - - - - Client messages > and server messages - >. - - - - TODO - - + - TODO - - - - Client messages > and server messages - >. - - - - Client messages >, server messages - ,10220|)>>. + <\itemize> + file protocol - + \; - Client messages >, server messages - ,10250|)>>. + system protocols (see section on OS design using NARP) - + UI protocols (terminal, GUI) - Protocols not discussed in this specification may use client messages with - type IDs > and server messages - >. Overlaps between several protocols are - allowed : the information about implemented interfaces for an object is - meant to disambiguate such situations. + communication protocols (mail, IM) + @@ -896,7 +867,121 @@ implementing a standard filing protocol, much like memory mapped files in standard OSes (only this would work with arbitrary ressources). - TODO + In this section we will develop on a concrete proposal for a NARP-based + operating system. + + + + The basic primitive of the system being message-passing, the system looks a + lot like a micro-kernel. Only the message format has a complex semantic and + the communication layer is not really ``simple''. Furthermore, the system + has device drivers, file system and networking running as kernel-mode + processes, making the kernel more monolithic (but still having a + micro-kernel spirit). It should be easy to make any user mode process run + as a kernel mode process instead, for the sake of performance (eg : + graphical server & compositor). + + The kernel land is divided in three major parts, with strict dependency + order: + + <\itemize> + Level 0 : System ressource managment : physical memory, virtual + memory, hardware interaction (IRQ, v86), debug output + + Level 1 : Scheduler, IPC & NARP core server : builds on top of + level 0, adds support for processes and communication between them + restricted to NARP protocol data. + + Level 2 : System processes : hardware, file systems, network, ... + (may access level 0 and level 1 features) + + + User processes are restricted to syscalls that call level 1 primitives. + + Here are a few basic principles for the design of these three levels : + + <\itemize> + Level 2 processes may not communicate directly nor share memory : + they must go through level 0 and level 1 primitives to achieve such a + goal. Each level 2 process has a separate heap, which is completely freed + when the process dies. Level 2 processes do not use separate virtual + memory spaces : since the kernel memory space is mapped in all page + directories, a level 2 process may run with any page directory. + + Benefits : critical system parts are restricted to level 0 and level 1. + Level 2 components may leak or crash with less consequences. + + All synchronization & locking is handle by level 1, except for + level 0 that must implement its own locking devices (since it cannot rely + on level 1). + + Benefits : no complex synchronization in most of the code (which is + either level 2 or userland), only simple message passing and waiting for + stuff to happen + + No concept of ``threads'' : system processes are actually kernel + threads, but we call them processes since they use separate parts of + memory. Userlands processes cannot spawn multiple threads of execution + either : they must fork and communicate through NARP if they want to do + so (eg: launching an expensive communication in the background). + + (since fork is a complicated system call, and features such as + copy-on-write depend on processes using different paging directories, the + fork system call is accessible only to userland processes : level 2 + processes may not fork, but only create new processes) + + Level 1 also has a memory heap ; it is used with + . Level 2 proceses use standard + , which are modified to act on the heap of the + current process. + + Each process (system or user) has a , ie a queue of + incoming NARP messages waiting to be transferred. The mailbox has a + maximum (buffer size), and a call may fail with a + error. This is the only possible failure for + a call. + + System processes (level 2) spend most of their time in + ; they may be waked up by either recieving a NARP messsage or by a + hardware event. Therefore the function that composes + the main loop may return either : or . If the reason is , + the process is free not to read the message immediately. + + On the other hand, user processes can wait for only one thing : recieving + a NARP message. Each user process has a in its memory + space, and the function just copies the first + message of the mailbox into this zone (overwriting whatever was there + before) and returns control to the process (returning the length of the + message). + + Handling of IRQs : some hardware stuff requires action as soon as + the interrupt is fired, therefore a specifi IRQ handler may be used. Such + a handler must do as little as possible, and when it is done signal level + 1 that an IRQ has happenned (it may add specific data to the ``IRQ + happenned'' message). Level 1 adds a message to the queue of the + recipient process (if there is one) and returns immediately : the IRQ + handler must leave as soon as possible. An IRQ is handled on whatever + stack is currently used, and the IF flag is constantly off while the IRQ + handler is running. The timer IRQ is the only one that behaves + differently, since it has to trigger a task switch. + + + + + <\enumerate> + Develop level 0 completely and with cleanest possible design + + Develop level 1 with only basic funcionnality + + Develop some basic applications in level 2 : display, keyboard, + mini kernel shell, mini file system, ... + + Improve level 1 with more complex stuff ; try to quickly attain a + complete level 1 + + Work on the rest of the stuff + <\initial> @@ -952,44 +1037,44 @@ > > > - > - > + > + > > > > > > > - > - > + > + > > - > - > - > - > - > - > - > - > - > - > + > + > + > + > + > + > + > + > + > + > > - > - > - > - > - > - > + > + > + > + > + > + > > > - > + > > > > > - > + > > - > + > @@ -1188,103 +1273,115 @@ |.>>>>|> > + |Unbox|\> + |.>>>>|> + > + + |Plug|\> + |.>>>>|> + > + + |Unplug|\> + |.>>>>|> + > + |3.4Big message protocol |.>>>>|> - > + > |3.5Authentification and rights managment commands |.>>>>|> - > + > |Authenticate|\> |.>>>>|> - > + > |NewToken|\> |.>>>>|> - > + > |NewTokenR|\> |.>>>>|> - > + > |3.6File protocol |.>>>>|> - > + > |3.7UI protocols |.>>>>|> - > + > |3.7.1Terminal protocol |.>>>>|> - > + > |3.7.2Graphical user interface protocol |.>>>>|> - > + > |3.8Communication protocols |.>>>>|> - > + > |3.8.1Email and newsgroups protocol |.>>>>|> - > + > |3.8.2Instant messaging protocol |.>>>>|> - > + > |3.9Other protocols |.>>>>|> - > + > |3.10Table of IDs |.>>>>|> - > + > |3.10.1Message types |.>>>>|> - > + > |Base protocol |.>>>>|> - > + > |Authentication & privileges |.>>>>|> - > + > |3.10.2Error messages |.>>>>|> - > + > |3.10.3Object interfaces |.>>>>|> - > + > |Servable |.>>>>|> - > + > |non-NARP inside |.>>>>|> - > + > |NARP service |.>>>>|> - > + > |math-font-series||4Architecture of a NARP implementation in OCaml or Haskell> |.>>>>|> - + |math-font-series||5Using NARP to design an Operating System> |.>>>>|> - + \ No newline at end of file -- cgit v1.2.3