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 > >