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

[Thomas D. Ward]

That is true, but there are many simple users who don't like going through
and building kernels everytime an update comes along.
Most of us on the list have experience with patching kernels, building them,
and installing them.
However, for newbies to Linux are fighting with the os, and learning how to
compile all at once. That's pretty tuff.
Fortunately, this problem is getting less and less now that there are kernel
rpms with speakup, Slack w=comes with it, etc.

----- Original Message -----
From: Gregory Nowak <greg at romuald.net.eu.org>
To: <speakup at braille.uwo.ca>
Sent: Wednesday, April 16, 2003 11:01 PM
Subject: Re: Kernel/user space (Was: Re: redhat problems)


> One problem I see with this idea is that if you get a kernel panic before
the rest of the package loads, you're up a creek without a sightling (grin).
>
> Greg
>
>
> On Wed, Apr 16, 2003 at 09:24:30PM -0500, Luke Davis wrote:
> > 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
> >
> >
>
> _______________________________________________
> Speakup mailing list
> Speakup at braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup