Speakup in userspace

[W. Nick Dotson]

Wow!  If I had you here as my mentor, I could learn that Linux stuff.  That just had to be the neatest bit of technical explanation I read in aeons...  I saved it 
in my Linux docs folder on my Windows machine...  (grin)

Nick

On Wed, 20 Jun 2007 13:53:35 -0500, Doug Sutherland wrote:

 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

 _______________________________________________
 Speakup mailing list
 Speakup at braille.uwo.ca
 http://speech.braille.uwo.ca/mailman/listinfo/speakup