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
