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

[Luke Davis]

Yes, but Janina makes a good point, about the speaking from startup.
Afaik, the only way to do that, is to have *some* hooks in the kernel;
hence my hybrid idea.

Luke


On Thu, 17 Apr 2003, Thomas D. Ward wrote:

> As I said in a previous post it may be possible to write a screen reader
> which would run as a system service.As such it would start as soon as the
> services such as sendmail, apache, postfix,
> got loaded. It might not have all the abilities of speakup, but I could see
> it being vary easy to install, expand, and wouldn't be kernel linked.
> Also another advantage is it could probably be ported to FreeBSD, and other
> operating systems.
> The problem is time, and man power.
>
> ----- Original Message -----
> From: Luke Davis <ldavis at shellworld.net>
> To: <speakup at braille.uwo.ca>
> Sent: Wednesday, April 16, 2003 10:24 PM
> 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
>
>
> _______________________________________________
> Speakup mailing list
> Speakup at braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>