Kernel/user space (Was: Re: redhat problems)

[Saqib Shaikh]

Hi

I am working on something very similar.  I am making a device file,
/dev/acsint, which exposes various accessibility information to userspace -
like what is being written to the screen, and what keys are being pressed.
It's not ready yet because I have my final exams coming up, but it will be
finished during the summer holidays.  I am then going to work with the
author of BrlTTY to add speech support.

Then you will have a daemon is userspace which provides full speech support.
I don't want to compete with Speakup - this is my prefered way of doing
things and one day I hope to make it a reality - many others will prefer the
philosophy of Speakup.

Thanks, Saqib


-----Original Message-----
From: speakup-admin at braille.uwo.ca
[mailto:speakup-admin at braille.uwo.ca]On Behalf Of Luke Davis
Sent: 17 April 2003 03:25
To: speakup at braille.uwo.ca
Subject: Kernel/user space (Was: Re: redhat problems)


Okay, since we're going to have this discussion, let's have it, under a
better subject...

Long before I started using Speakup, I was apposed to having it in the
kernel, for all manner of reasons.

However, after using it a bit, and learning more about how it worked, I
became less attached to that idea, and started looking at it as more of a
driver, of the display type, and thus as something that needed to be in
the kernel.  At least, my arguments against it, lost some major weight.

As it stands, I am happy with Speakup as it is--in the kernel.  I still
maintain, however, that there may be a better way.

What I am looking at (unless Kirc, et al already did), is whether a hybrid
solution is possible--part in the kernel, and part in user space.

The only part that (and this is said with an admited lack of knowledge on
certain things, and is as such subject to change without notice) needs to
be in the kernel, is what is, at minimum, required to access the consoles,
and *maybe* talk to the synths.
I am hoping that some parts can be moved out of the kernel, while still
retaining the full functionality of Speakup as it is.  At the very least,
buffering of data will be necessary.  What I mean is, that when output
starts to a console (such as when booting starts), data will be buffered
until the rest of the package, or at least what is needed to speak, is
loaded, either from initrd, or from the root fs.  This is necessary for
some hardware synths (DEC PC), and software synths, anyway, and as such
should not be as strange as it initially looks.

The questions, as I see them, are:
(1) is this a feasable idea; and
(2) can enough of Speakup be moved into user space to make this worth
doing?

I do not know the answers to those yet.

However, that is my active idea.  Pleese feel free to change my mind.

What I am thinking, is that if this can be made to happen, the kernel
parts can be made highly stable, while the rest (managing the data which
the kernel parts provide), can be as unstable as may be necessary.

 Luke


On Wed, 16 Apr 2003, Janina Sajka wrote:

> But then it wouldn't be Speakup. If you prefer it, you should consider
deferring to the possibility that its presence in the kernel is the very
reason you like it so
> well.
>
> Do you think you'd have access to any console if Speakup loaded further up
the stack? I happen to think access to any console is a very big deal, and
very much an
> equalizer. After all, everyone else has that, even if they choose not to
use it.

_______________________________________________
Speakup mailing list
Speakup at braille.uwo.ca
http://speech.braille.uwo.ca/mailman/listinfo/speakup