From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vms048pub.verizon.net ([206.46.252.48]) by speech.braille.uwo.ca with esmtp (Exim 3.36 #1 (Debian)) id 1I1Meu-0003Em-00 for ; Thu, 21 Jun 2007 09:25:12 -0400 Received: from ALBERTLC7SN0ZA ([68.163.238.66]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JJZ00BUEMLC47HK@vms048.mailsrvcs.net> for speakup@braille.uwo.ca; Thu, 21 Jun 2007 08:24:50 -0500 (CDT) Date: Thu, 21 Jun 2007 09:25:27 -0400 From: "Albert E. Sten-Clanton" Subject: Re: Speakup in userspace To: "Speakup is a screen review system for Linux." Message-id: <005c01c7b407$a2c15b20$6405a8c0@ALBERTLC7SN0ZA> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Mailer: Microsoft Outlook Express 6.00.2800.1807 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Priority: 3 X-MSMail-priority: Normal References: <20070620103329.GI4837@implementation.labri.fr><00f501c7b338$312865a0$ab00a8c0@tenstac><20070620124917.GB5078@implementation.labri.fr><20070620154008.GA2616@riley> <001c01c7b35e$15d448c0$6405a8c0@ALBERTLC7SN0ZA> <007b01c7b36c$4ebfc8e0$ab00a8c0@tenstac> X-BeenThere: speakup@braille.uwo.ca X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Speakup is a screen review system for Linux." List-Id: "Speakup is a screen review system for Linux." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2007 13:25:13 -0000 Thanks very much for the explanation below. Al ----- Original Message -----=20 From: "Doug Sutherland" To: "Speakup is a screen review system for Linux." = 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"=20 > operating system as opposed to "real mode". Protected mode > allows access to things like virtual memory, multi-threading,=20 > and priviledge levels not available in real mode. Protected=20 > mode has been the standard on x86 PCs since the 80286. >=20 > A protected mode system segregates virtual memory into=20 > 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=20 > can be swapped to disk. >=20 > User space or "userland" processes cannot access the memory > of other processes, the basis of memory protection which=20 > makes linux very stable. Prior to win2k, the windows os was=20 > not a protected memory system, hence the freezing up or=20 > 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.=20 >=20 > 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=20 > and user processes. The kernel processes are supposed to=20 > be basic things like the direct interface to hardware. User > space is where applications run. So there is kernel space=20 > memory, threads, and processes, and user space memory,=20 > threads, and processes.=20 >=20 > 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=20 > kinds of things without touching kernel code. The alsa-lib=20 > 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. >=20 > 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=20 > that actually talks to the synth would ideally be abstracted=20 > 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=20 > same. An example of a very well abstracted API is the=20 > Java API. It had to be done that way in order to make the > programs portable on different systems. I may be biased=20 > because I used to work there, but if you look at how much > work was done on abstraction it's the most impressively=20 > abstracted API around. I'm not talking about javascript,=20 > that's like a virus hehe. Unfortunately Sun wanted Java to=20 > 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=20 > parts of it are separate APIs, and the compact versions=20 > like J2ME are still very efficient. They run on almost all=20 > 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. >=20 > -- Doug >=20 > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup >=20 >=20 > --=20 > No virus found in this incoming message. > Checked by AVG Free Edition.=20 > Version: 7.5.472 / Virus Database: 269.9.1/854 - Release Date: = 6/19/2007 1:12 PM >=20 >