Speakup in userspace

[Doug Sutherland]

Consider the linux that most of use to be a "protected mode" 
operating system as opposed to "real mode". Protected mode
allows access to things like virtual memory, multi-threading, 
and priviledge levels not available in real mode. Protected 
mode has been the standard on x86 PCs since the 80286.

A protected mode system segregates virtual memory into 
kernel space and user space. Kernel space is strictly reserved
for running the kernel, device drivers, and kernel extensions.
It is usually the case that kernel space memory is not swapped
to disk since that is much slower, which user space memory 
can be swapped to disk.

User space or "userland" processes cannot access the memory
of other processes, the basis of memory protection which 
makes linux very stable. Prior to win2k, the windows os was 
not a protected memory system, hence the freezing up or 
crashing of whole system from one bug in one driver or app.
A user space process, although restricted in memory access,
can request the kernel to map part of its memory onto its own
space, and can also access shared memory. 

The kernel space is the direct hardware access space along
with the management software that controls virtual memory,
DMA, threads, processes, etc. You have kernel processes 
and user processes. The kernel processes are supposed to 
be basic things like the direct interface to hardware. User
space is where applications run. So there is kernel space 
memory, threads, and processes, and user space memory, 
threads, and processes. 

Consider ALSA sound as an example. It's in the kernel but
it's also not in the kernel. There are kernel drivers and there
are user space libraries. The alsa-lib delegates sound control
to user space. This allows application developers to do all 
kinds of things without touching kernel code. The alsa-lib 
provides various functionality like software mixing, support
for the older OSS API, and user specific configuration, and
it is multi-thread safe, essential for complex audio programs.

Alsa may not be the best example, but the idea is separating
the core functionality from the application layer. Let's say I
create an API for writing text to a speech synth. The code 
that actually talks to the synth would ideally be abstracted 
from the API such that the identical programming interface
works for any synth using any protocol like serial or usb.
Some hardware may not implement all parts of the API but
where there are same functions the API should look the 
same. An example of a very well abstracted API is the 
Java API. It had to be done that way in order to make the
programs portable on different systems. I may be biased 
because I used to work there, but if you look at how much
work was done on abstraction it's the most impressively 
abstracted API around. I'm not talking about javascript, 
that's like a virus hehe. Unfortunately Sun wanted Java to 
be the answer to everything everywhere which it is not and
will never be, and Java, like many good ideas, has become
overly bloated and complex, although at least the various 
parts of it are separate APIs, and the compact versions 
like J2ME are still very efficient. They run on almost all 
phones now. There is a good reason for this. I wrote some
apps on blackberry and it was a breeze to do so. Compared
with doing it in C or ASM it's an entirely different world.

  -- Doug