]> pilppa.com Git - linux-2.6-omap-h63xx.git/commit
[PATCH] uml: mconsole fixes
authorAl Viro <viro@ftp.linux.org.uk>
Tue, 24 Oct 2006 10:15:29 +0000 (11:15 +0100)
committerLinus Torvalds <torvalds@g5.osdl.org>
Wed, 25 Oct 2006 05:01:10 +0000 (22:01 -0700)
commit3a51237dc11efe283b40ea0248f4e26ab935dbd1
treed27f5f2cbaea27119914186650739f281f796e77
parent6c50444723f2e6487b3377450f90d813a88e6c31
[PATCH] uml: mconsole fixes

 * 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: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
arch/um/drivers/mconsole_kern.c
arch/um/drivers/mconsole_user.c
arch/um/include/mconsole.h