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

[Janina Sajka]

Fine, Luke, but you're not the only one to think this way, and you may not even be the first.

This is what is known as modularity. It's why we have kernel loadable modules, which can be passed arguments at the boot> prompt, etc., etc.

If I read this list correctly, early and certainly broken versions will soon be popping out of CVS. Eventually, it'll be called Speakup 2.0. 

So, relax. It's all in the chute.

PS: How's that beginner doc coming along?

Luke Davis writes:
> From: Luke Davis <ldavis at shellworld.net>
> 
> 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

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina at afb.net		Phone: (202) 408-8175