> Doesn't the kernel already contain a keyboard mapping table?

Yes.

> Couldn't you
> just set up a section to malloc a section of memory and copy the kernel's
> internal table there and change the references throughout the kernel to
> point to that new memory location, so that the only thing that must be
> passed from one section of the kernel to another is a single pointer to
> the new start-of-map location?

Probably only one global (or file scope) variable has to be changed to
point the new map.  The new map could be newly malloc()ed or it could
be loaded overwriting the existing table.  It's a design issue and
there's no single "Right" solution.  I think one of the saner design
would be to copy a new map from the user space into single table in the
kernel space, but keep the default map around which can be loaded by
some unlikely key combinations in case of screw-ups.

> Or for that matter, other programs access a "symbol table" within the
> kernel to determine the locations of data that they need (ps, netstat,
> etc.), right?

Maybe you could, but all the kernel symbols don't get saved.  It's much
cleaner to set aside a ioctl() function for the job.

> Just add another pointer in that table that points to the
> permanent location of the keymapping within the kernel.  Then, allow a
> program that runs on startup to change that section of the running copy of
> the kernel.  I know, I know... it's not a good idea to change the kernel
> while it's running.

It is not especially when modified by a userland program.  How do you
ensure that the changes being made are done *atomically*?  On the
contrary, if you do this with ioctl(), you do the "Real" job in the
kernel space, so it's almost guaranteed to run atomically.

ken