Solaris 10 released, with accessibility built-in! Also FreeTTS 1.2 released. (fwd)

Dave Mielke dave at mielke.cc
Fri Feb 25 18:59:35 UTC 2005


[quoted lines by Kenny Hitt on 2005/02/25 at 11:48 -0600]

>Since Brltty isn't in the kernel, it might already work on Solaris.  

Yes, it does, although, strictly speaking, not as well as on Linux when the
console is in text mode. When the console is in graphics mode, however, the
access is the same since both platfrms rely on Gnopernicus. 

The reason for the difference when the console is in text mode is that Solaris
doesn't offer a way for a user-space application to directly read the screen
content in the same way that Linux's /dev/vcsa devices do. Now that Solaris is
open source, though, this may be something which can be more easily resolved.
Given Sun's commitment to the open source community, I wouldn't be surprised if
they'd accept a well-written kernel patch which provides the needed capability. 
It may even be that, once brought to their attention, a Sun engineer might take
up the challenge.

In the mean time, of course, BRLTTY can still be used when the Solaris console
is in text mode by using it in conjunction with a patched version of the screen
program. A patch for screen can be found in BRLTTY's source tree (in the
Patches subdirectory) which causes it to maintain an image of the screen in a
shared memory segment. BRLTTY can then be built with its shared memory (shm)
screen driver. Solaris 10 already includes this combination, i.e. the patched
version of screen and BRLTTY built with its shm screen driver.

>Developers of Yasr and Brltty
>please don't take my next statement the wrong way, but writing kernel
>patches is more challenging than writing user space screen readers.

As already noted, for BRLTTY to work at its best, it, too, relies on
kernel-resident capabilities which aren't part of all Unix flavours. If those
capabilities aren't provided by some given platform then it'll still work (when
used in conjunction with screen), but not nearly as well. Kernel patches,
therefore, may still be necessary.

>Programs running in user space can do things that just aren't a good
>idea in the kernel.  One example is any task that takes a large amount
>of time.  Time used by a screen reader in kernel space is time lost to
>the whole system, while time used by a user space screen reader only
>effects the performance of the screen reader.

That's not true. The processor's time is always devided up amongst all of the
various tasks which need to be done, whether they're in the kernel or in
user-space. It's just that tasks which run within the kernel can't be easily
preempted so it's typically as though they're implicitly running at maximum
priority. This, in turn, can cause the rest of the system to have much less of
an interactive feel.

This being said, most Unix flavours nowadays offer kernel threads. It's now
quite possible, therefore, for tasks requiring large amounts of time to be
implemented right within the kernel without destroying the interactive nature
of the system in any way. Those tasks just need to be implemented as kernel
threads rather than as in-line code.

There's really only one reason why it's far better to implement an application
in user-space, and that reason is big. There are no standards insofar as what
any provider's kernel programming environment is like whereas all providers do
try (some much more than others) to offer Posix-based user-space environments.
>From the perspective of an application writer, therefore, it's far easier to be
platform-independent in user-space. Put another way, it's incredibly expensive
for a kernel-based application (like Speakup) to be provided on multiple
platforms since very little of its code may actually be reusable.

-- 
Dave Mielke           | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario   | Word of God. Please contact me
EMail: dave at mielke.cc | Canada  K2A 1H7   | if you're concerned about Hell.
http://FamilyRadio.com/                   | http://Mielke.cc/bible/




More information about the Blinux-list mailing list