> 2. I'd really prefer to see callers use
> register_sysrq_key() and unregister_sysrq_key() so that they
> can get/use return values, and not the lower-level functions
> "__sysrq*" functions that are EXPORTed in sysrq.c.
> I don't see a good reason to EXPORT all of these functions.
So would I, however, the lower interface is there so that modules can
restructure the table in more complex ways, allowing for sub-menus.
The really good answer here is to add registration functions for the top
level handler, so that sub handlers can just claim the top level events
without mucking with the table, and then restore the table handler
later. This allows really modeful handlers, with submenus, and
potentially even key entry. An example would be a handler to kill a
specific process.
I'm also looking at a patch from Amazon which allows sysrq to be
'sticky', to get arround bad keyboards and VTs, and allows which key the
magic key is to be setable, to get arround VTs lacking sysrq entirely.
I am reviewing the things I apparently horked, and this amazon stuff
(which is very small) at the moment. Expect a pair of patches tomorrow,
or late tonight.
Ps. I am very embarassed about the log-level stuff.
--
Crutcher <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 23 2001 - 21:00:45 EST