public inbox for speakup@linux-speakup.org
 help / color / mirror / Atom feed
From: "Albert E. Sten-Clanton" <albert.e.sten_clanton@verizon.net>
To: "Speakup is a screen review system for Linux." <speakup@braille.uwo.ca>
Subject: Re: Speakup in userspace
Date: Thu, 21 Jun 2007 09:25:27 -0400	[thread overview]
Message-ID: <005c01c7b407$a2c15b20$6405a8c0@ALBERTLC7SN0ZA> (raw)
In-Reply-To: <007b01c7b36c$4ebfc8e0$ab00a8c0@tenstac>

Thanks very much for the explanation below.

Al
----- Original Message ----- 
From: "Doug Sutherland" <doug@proficio.ca>
To: "Speakup is a screen review system for Linux." <speakup@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@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
> 
>


  parent reply	other threads:[~ UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
 Tyler Spivey
 ` Luke Yelavich
   ` Samuel Thibault
     ` Luke Yelavich
       ` Samuel Thibault
 ` Doug Sutherland
   ` Samuel Thibault
     ` Doug Sutherland
       ` Samuel Thibault
         ` Christopher Moore
           ` Samuel Thibault
           ` Albert E. Sten-Clanton
             ` Doug Sutherland
               ` W. Nick Dotson
               ` Albert E. Sten-Clanton [this message]
             ` Deborah Norling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='005c01c7b407$a2c15b20$6405a8c0@ALBERTLC7SN0ZA' \
    --to=albert.e.sten_clanton@verizon.net \
    --cc=speakup@braille.uwo.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).