diff options
| -rw-r--r-- | doc/gui-stack-design.md | 32 | ||||
| -rw-r--r-- | doc/roadmap.md | 32 |
2 files changed, 49 insertions, 15 deletions
diff --git a/doc/gui-stack-design.md b/doc/gui-stack-design.md index b545520..5da0eeb 100644 --- a/doc/gui-stack-design.md +++ b/doc/gui-stack-design.md @@ -1,6 +1,36 @@ (sorry, in french for the moment) -# Design de la pile GUI +GUI stack design +================ + +Two protocols : + +- GIP (Graphics Initiation Protocol) : one GIP session handles one graphical + framebuffer, a keyboard, a mouse. The buffer is created by the server and + shared to the client with a token (a kernel IPC mechanism for file + descriptors). Reset operation. Possible extention for audio input/output to be + done at this level. +- WMP (Window Management Protocol) : creation of windows and of a GIP channel + for interacting with each window. Usual window managing messages. Hierarchy of + WMP channels : in a WMP channel you can ask for the creation of a sub-channel + ; when a channel is closed all the sub-channels are closed too. + +Software components of the GUI stack : + +- `giosrv` handles the i/o with the hardware and makes that available as a GIP + channel +- login manager : talks to `giosrv`, displays the login manager, and once a + user is logged in, simply proxies the GIP between `giosrv` and the user + desktop manager. Intercepts Ctrl+Alt+Del to lock the current session and go + back to login screen. +- sessin manager : instantiated by login manager, runs with the privileges of + the user. Window managing. +- graphical toolkit library + + +---- + +Version française. Deux protocoles : diff --git a/doc/roadmap.md b/doc/roadmap.md index fb5b8b2..a8871ae 100644 --- a/doc/roadmap.md +++ b/doc/roadmap.md @@ -1,12 +1,15 @@ -# Roadmap +Roadmap +======= -## Plans for soon +Plans for soon +-------------- * Write device drivers : keyboard, FAT (or EXT2 ?) * Work on userland : init, terminal emulator, shell -* GUI server with help from kernel for framebuffer management +* GUI server (with help from kernel for framebuffer management ?) -## Things to design +Things to design +---------------- * Reclaiming physical memory : - Freeing some cached stuff, ie swapping pages from mmap regions @@ -16,23 +19,24 @@ * How does a process transmit information (such as environment, arguments, file descriptors) to its children ? * How do we do stream-like IO on files ? (ie how do we implement the append -* access mode - and non-position-dependant read/write calls & seek call) + access mode and non-position-dependant read/write calls & seek call) * Better error reporting for system calls that fail -## Things not sure +Things not sure +--------------- * VFS thread safety : is the design correct ? (probably) * Cache architecture (called *pager*, after 4.4BSD terminology) * Not enough tests! -## Plans for the later future +Plans for the later future +-------------------------- * Define a format for "packages", i.e. read-only filesystem images used for -* adding system - components or apps to the OS ; make sure to implement it in a way that does - not waste memory -* Module system for extending the kernel In userspace, simple Scheme-like -* scripting language POSIX compatibility layer, self-hosting OS The obvious -* stuff ;-) + adding system components or apps to the OS ; make sure to implement it in a way + that does not waste memory +* Module system for extending the kernel In userspace +* simple Scheme-like scripting language +* POSIX compatibility layer, self-hosting OS +* The obvious stuff ;-) |