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
>
>
next prev 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).