From e5eb1000c717581ae23734d56c38903ae3215cb2 Mon Sep 17 00:00:00 2001 From: Alexander Boettcher Date: Fri, 26 Feb 2016 10:38:38 +0100 Subject: [PATCH] nova: remove obsolete parts of documentation --- repos/base-nova/doc/nova.txt | 46 +++--------------------------------- 1 file changed, 3 insertions(+), 43 deletions(-) diff --git a/repos/base-nova/doc/nova.txt b/repos/base-nova/doc/nova.txt index bb5950d6d..14ba82f47 100644 --- a/repos/base-nova/doc/nova.txt +++ b/repos/base-nova/doc/nova.txt @@ -113,7 +113,7 @@ on NOVA: * Core runs directly as roottask on the NOVA hypervisor. On startup, core maps the complete I/O port range to itself and implements debug output via - comport 0. + the serial/UART I/O ports defined by the BIOS data area. * Because NOVA does not allow rootask to have a BSS segment, we need a slightly modified linker script for core (see 'src/core/core.ld'). @@ -132,7 +132,7 @@ on NOVA: needed to perform RPC requests is provided by the client during the RPC call. This way, RPC semantics becomes very similar to function call semantics with regard to the accounting of CPU time. Genode already distinguishes normal - threads (with CPU time) and server-side RPC handlers ('Server_activation') + threads (with CPU time) and server-side RPC handlers ('Rpc_entrypoint') and, therefore, can fully utilize this elegant mechanism without changing the Genode API. @@ -152,37 +152,6 @@ on NOVA: not consume a kernel resource, and second, the full semantics of the Genode lock including the 'cancel-blocking' semantics are preserved. -* NOVA does not support server-side out-of-order processing of RPC requests. - This is particularly problematic in three cases: Page-fault handling, signal - delivery, and the timer service. - - A page-fault handler can receive a page fault request only if the previous - page fault has been answered. However, if there is no answer for a - page-fault, the page-fault handler has to decide whether to reply with a - dummy answer (in this case, the faulter will immediately raise the same page - fault again) or block until the page-fault can be resolved. But in the latter - case, the page-fault handler cannot handle any other page faults. This is - unfeasible if there is only one page-fault handler in the system. Therefore, - we instantiate one pager per user thread. This way, we can block and unblock - individual threads when faulting. - - Another classical use case for out-of-order RPC processing is signal - delivery. Each process has a signal-receiver thread that blocks at core's - signal service using an RPC call. This way, core can selectively deliver - signals by replying to one of these in-flight RPCs with a zero-timeout - response (preserving the fire-and-forget signal semantics). On NOVA however, - a server cannot have multiple RPCs in flight. Hence, we use a NOVA semaphore - shared between core and the signal-receiver thread to wakeup the - signal-receiver on the occurrence of a signal. Because a semaphore-up - operation does not carry payload, the signal has to perform a non-blocking - RPC call to core to pick up the details about the signal. Thanks to Genode's - RPC framework, the use of the NOVA semaphore is hidden in NOVA-specific stub - code for the signal interface and remains completely transparent at API - level. - -* Because NOVA provides no time source, we use the x86 PIT as user-level time - source, similar as on OKL4. - * On the current version of NOVA, kernel capabilities are delegated using IPC. Genode supports this scheme by being able to marshal 'Capability' objects as RPC message payload. In contrast to all other Genode base platforms where @@ -209,14 +178,7 @@ with NOVA looks as follows, whereas 'genode/' is a symbolic link to the ! module /genode/init ! module /genode/timer ! module /genode/nitpicker -! module /genode/liquid_fb -! module /genode/launchpad -! module /genode/scout -! module /genode/testnit -! module /genode/nitlog -! module /genode/pci_drv -! module /genode/ps2_drv -! module /genode/fb_drv +! ... Limitations ########### @@ -231,5 +193,3 @@ The current limitations are: * For portals used as exception vectors for threads, the thread causing the exception and the handler thread which is bound to the exception portal must be on the same CPU. - -* Priorities for Genode threads are not supported.