Thanks very much for the explanation below. Al ----- Original Message ----- From: "Doug Sutherland" <doug@xxxxxxxxxxx> To: "Speakup is a screen review system for Linux." <speakup at braille.uwo.ca> Sent: Wednesday, June 20, 2007 2:53 PM Subject: Re: Speakup in userspace > 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 > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.472 / Virus Database: 269.9.1/854 - Release Date: 6/19/2007 1:12 PM > >
