* when we have stop/sysrq/go, we get pt_regs of whatever executes
   mc_work_proc().  Would be better to see what we had at the time of
   interrupt that got us stop.

 * stop/stop/stop.....  will give stack overflow.  Shouldn't allow stop
   from mconsole_stop().

 * stop/stop/go leaves us inside mconsole_stop() with
	os_set_fd_block(req->originating_fd, 0);
	reactivate_fd(req->originating_fd, MCONSOLE_IRQ);
   just done by nested mconsole_stop().  Ditto.

 * once we'd seen stop, there's a period when INTR commands are executed
   out of order (as they should; we might have the things stuck badly
   enough to never reach mconsole_stop(), but still not badly enough to
   block mconsole_interrupt(); in that situation we _want_ things like
   "cad" to be executed immediately).  Once we enter monsole_stop(), all
   INTR commands will be executed in order, mixed with PROC ones.  We'd
   better let user see that such change of behaviour has happened.
   (Suggested by lennert).

 * stack footprint of monsole_interrupt() is an atrocity; AFAICS we can
   safely make struct mc_request req; static in function there.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Acked-by: NJeff Dike <jdike@addtoit.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>