Re: [patch] 2.4.0-test6-pre8: Magic SysRq fixes for serial.c

From: Philipp Rumpf (prumpf@parcelfarce.linux.theplanet.co.uk)
Date: Wed Aug 09 2000 - 08:08:28 EST


On Wed, Aug 09, 2000 at 02:33:01PM +0200, Maciej W. Rozycki wrote:
> On Wed, 9 Aug 2000, Philipp Rumpf wrote:
> > That's just not true. handle_sysrq now exits without action if
> > sysrq_enabled == 0. In fact the only reason it's a global variable is
> > because sysctl requires it - hopefully that will be fixed in 2.5 (ELF
> > section based sysctl).
>
> That doesn't mean serial.c doesn't handle it. If handle_sysrq() exits
> without an action, then serial.c just drops the just received character
> (if any) on the floor

Yes.

> and also the next one provided it arrived in the
> SysRq recognition interval.

No.

> So it needs to be fixed anyway.

No. Dropping the character is perfectly fine - it's the same thing that
happens on the keyboard (now), and it's about as complex as a hack like
SysRq should be, IMHO.

> Ugh, I admit I haven't actually checked it even though I should have to.
> But this poses a problem in serial.c (and possibly other serial drivers,
> too) -- it needs to check if SysRq is enabled even before calling
> handle_sysrq().

No it doesn't. The character after a break gets handled the way it should
be - it gets interpreted as magic sysrq event, passed on to handle_sysrq,
and we forget about it. It just happens to be a nop cause all SysRq keys
are when sysrq_enabled == 0.

> Otherwise the character immediately preceding the BREAK
> condition gets lost for no reason.

Not sure I'm following - the character preceding a break condition shouldn't
be affected, unless you're talking about the 0 byte that gets put in the
FIFO for every break condition, which should get dropped.

> I don't think it's feasible to introduce sysrq_enabled() function or
> alike now that the variable is to be local.

Or we could just stop putting hacks in there and tell people to compile
without sysrq if they want to handle serial break events / alt-sysrq-x
combinations themselves.

        Philipp Rumpf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:18 EST