Commit 26a7f571 authored by Charles Jacobsen's avatar Charles Jacobsen Committed by Vikram Narayanan

Finished readme.

parent ae1936d7
This documents the first draft of the prototype.
......@@ -18,4 +19,111 @@ consists of:
Building and Running
In the kernel menuconfig, under the drivers submenu, select
\ No newline at end of file
In the kernel menuconfig, under the drivers submenu, select:
-- LCD Prototype
-- LCD Prototype API
-- LCD Prototype LibLCD
-- LCD Prototype Test (for 4 test modules)
-- LCD Prototype run tests in LCD (yes/no)
sudo make modules_install install
To run, insert the modules in this order:
-- api/lcd-prototype-api.ko (runs basic regression tests)
-- liblcd/lcd-prototype-liblcd.ko (does nothing on init)
-- test/lcd-prototype-test-dealer.ko (does nothing on init)
-- test/lcd-prototype-test-manufacturer.ko (does nothing on init)
-- test/lcd-prototype-test-customer.ko (does nothing on init)
-- test/lcd-prototype-test-boot.ko (inits lcd's and runs modules)
Code Layout
-- api-private header for definitions (capability subsystem and ipc);
for simplicity, I ended up using this header in the liblcd module
-- contains init/exit for api module
-- simple capability system, with one global lock
-- simple ipc primitives using synchronous endpoints
-- definitions used by test modules, and some used by all code (LCD_ERR
-- simple `data store' implementation (the `multiple internal cspaces'
component of our design)
-- test modules
Each test module (e.g., dealer.ko) has the original source file (dealer.c)
and the idl glue code (dealer-idl.c and dealer-idl.h).
IPC calls and api calls go into a header or liblcd, providing *code-level*
isolation, for simplicity. For example, a thread in dealer-idl.c calling
lcd_send eventually calls __lcd_send inside the api module.
For simplicity, the api code does not run in its own kernel thread, nor
does it interact with the lcds via any ipc.
This tests some of the decomposition patterns, but not isolation.
Test Modules
The test modules consist of:
-- a customer
-- a (car) dealer
-- a (car) manufacturer
-- a boot module
The test consists of building a simple data structure and passing it between
the three test lcds:
struct automobile
--- int doors
--- struct engine
--- int cylinders
The boot sequence is roughly as follows:
[ 1 ] boot.ko builds the lcd's and initializes kernel threads to run the
three modules; it also creates a sync endpoint for the dealer for its
interface, provided to all three modules at boot
[ 2 ] dealer.ko listens on its endpoint; customer.ko waits until
dealer.ko says the manufacturer is ready
[ 3 ] manufacturer.ko registers its interface with dealer, and dealer
signals to customer.ko (via a struct completion) that it's ready
[ 4 ] customer.ko buys a car from dealer.ko
[ 5 ] dealer.ko creates an engine and automobile using manufacturer's
interface, and allocates a shadow copy of the data; passes a
capability back to the customer for the data
[ 6 ] customer.ko frees the data, by using the capability provided by
the dealer; in the process, the customer and dealer deallocate their
shadow copies of the data
[ 7 ] customer.ko tells dealer.ko to die, which in turn tells
manufacturer.ko to die, and all three kthreads exit back to boot.ko
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment