On Sat, 1 Mar 2003, Kirk Reiser wrote: > Well, you have to keep some things in mind when discussing or thinking > about changes to speakup for whatever reason: one is speakup is kernel > code. Two is speakup is kernel code. 'grin' Man, have I noticed.:) > What I mean is the fewer things you can do in kernel code the better. I will leave this here, as the cardinal rule of design. I am one of those who believes speakup probably shouldn't be in the kernel to begin with, but I do not trust my abilities even a fraction enough to tackle that perceived problem, and I am wavering ever so slightly as to whether it is, in fact, a problem. Still, the above statement has the ring of moral authority with me, so worry not. > So saying all of the above I would not recommend changes to speakup to > change it's settings directly because of the amount of time which > would need to be spent in kernel space to accomplish those changes. > Specifically I mean writing functions which would have to wait for > user input of data such as rate changes because of the time involved. No no no! Any changes would be done either by a user level program. The only thing that speakup would have to do, is load a binary file (don't like that idea, because it would be arch specific), file of number sets which had meaning only to speakup (bad because the users could too easily corrupt it), or hex file.
