Skip to content

Instantly share code, notes, and snippets.

@milesrout
Created January 18, 2014 05:18
Show Gist options
  • Save milesrout/18c027d962e21ed2d279 to your computer and use it in GitHub Desktop.
Save milesrout/18c027d962e21ed2d279 to your computer and use it in GitHub Desktop.
OS Interface
OS Interface:
It has a layered interface.
It needs to work on different platforms, such the TR3200, the DCPU-16 and the DCPU-16e.
Therefore it needs to split the following up:
User mode user processes (Layer 4)
User mode system processes (layer 3)
Architecture-independent kernel code (layer 2)
Architecture-specific kernel code (layer 1)
Standalone object code archives that the kernel can load at runtime are called "extensions" as a whole.
The 2-1 interface is called the "driver interface", and level 1 extensions are called "drivers".
The 2-2 interface is called the "module interface", and level 2 extensions are called "modules".
The 2-3 interface is called the "service interface", and level 3 extensions are called "services".
Drivers and modules run in kernel mode. Services run in user mode.
Drivers are architecture-specific. Modules and services are architecture-independent.
Drivers are architecture-specific extensions that run in kernel mode.
Modules are architecture-independent extensions that run in kernel mode.
Services are architecture-independent extensions that run in user mode.
You would write a driver over a module when you need access to hardware and/or architecture-specific facilities.
You would write a module over a driver when your extension has general applicability over multiple architectures.
You would write a module over a service for performance reasons, or because you must do something privileged to the kernel.
You would write a service over a module if some context switching won't hurt performance too badly, performance isn't critical, and you want the security of being unable to crash the system.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment