Modularisation

[Kirk Reiser]

Hi Saqib:  In reference to your first post, I outlined in a message
last night exactly what it means to have speakup included in the
2.4.9ac15 patch set.  The fact that 2.4.9ac15 was released after
2.4.10 does not mean that this stuff has already been included in the
kernel.  You can read more about how the kernel tree gets built from
my previous note on the differences between ac, ae and pre-releases.

"Saqib Shaikh" <ss at saqibshaikh.com> writes:

> While I think that it is good that parts of Speakup has been included in the
> kernel, I would still like to see Speakup be a kernel module so that it can be
> added/removed at will.  What do people think of this?

Doesn't matter what anyone thinks of the idea.  Unless someone is
willing to get involved and write a lot of code it will never happen.
Plain and simple.  I am not at all interested in making speakup a
module.

> Secondly, I personally don't like the fact that one must change the keymaps to
> use Speakup.  Could Speakup be changed so that it monitors all keypresses, and
> if it wants to deal with them it does so and then all other keys are passed
> through?  This would, in my opinion, be a far better solution.

This is a sentiment which is often expounded by folks that know sweet
fuck all about how the kernel actually works.

Key presses generate a hardware interrupt.  The interrupt handler does
a very quick function lookup in an array of functions and then
schedules them for processing in a bottom-half routine.  It then
returns to it's regularly scheduled programming.  So just exactly
where are you going to start examining key presses?  You aren't
suggesting we hold up the entire machine while we decide what to do
with a key are you?

I am writing this article because I am very happy you are thinking
about these things.  But! quit making sweeping suggestions until you
know what the fuck you are talking about.

On the other hand, there are number of things which can be done to
help work around some of the issues you have raised above. 

1. Put together a set of keymaps with the speakup functions included
   for all of the standard international keymaps made available by the
   popular distributions.  We could then make that available on the
   speakup web site.

2. Instead of the above, come up with a common diff which could be
   applied to any keymap to include the speakup review functions.  Any
   distribution maintainer could then patch whichever keymap was
   selected if speakup was chosen.

3.  Write some kernel/speakup code to flip the review pad in and out
    when the numlock key is toggled.  This is on my to-do list but
    down a way.

> Finally I would like to raise the issue of security.  Many of my friends at
> universities in the UK use Emacspeak rather than Speakup purely because our
> universities consider patching every kernel both a security risk and a
> hastle.  

That is just plain stupid.  It tells me two things, they don't care
about they're blind students and that they know nothing about security
themselves.  That is scary!

On the security side I also know of at least one distribution that
> refuses to include Speakup because of it being a security risk.

Who?  I have not ever heard this from any of the distributions.  It
just doesn't make sense.

> Any comments welcome.  If there's anything I can do to help rectify the
> possible flaws above let me know.

There you go.  Comments suggestions and criticism all in one post.
What more could a guy ask for?  Now, quit bitching and start coding.

  Kirk

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: kirk at braille.uwo.ca		University of Western Ontario
phone: (519) 661-3061