Re: [PATCH] Magic SysRq alternate fix register functions

["Randy.Dunlap" <rddunlap@osdlab.org>]

Crutcher Dunnavant wrote:
> 
> ++ 21/09/01 18:22 -0400 - Crutcher Dunnavant:
> > I'm not sure if this is sufficient. The low level interfaces need to be
> > exposed, and if we are not expecting modules to pay attention to the
> > CONFIG_MAGIC_SYSRQ setting, then the all of these interfaces need to be
> > overridden.
> >
> > However, do we even need this #ifdef CONFIG_MAGIC_SYSRQ block at all?
> > What does it matter if modules register or unregister events, if they
> > cannot be called?
> >
> > The old code only zaped the enable if sysrq was not defined, and that is
> > what I'm doing in the table. Some real changes would be neccessary to
> > actually drop out the whole system.
> >
> > There is also no real reason to try and no-op these functions for speed,
> > as they are trivial and FAR outside of the main call path.
> >
> > So the way to go I see here is:
> >  a) allow the registration functions to always be defined.
> > and either:
> >  b) handle the return failure in the __sysrq_XXX functions themselves,
> >  c) or not.
> 
> A 'dont-close-it' patch is attached.
> 
>   ----------------------------------------------------------------------
>  Name: patch-2.4.10-pre13-sysrq_register
>  patch-2.4.10-pre13-sysrq_register       Type: Plain Text (text/plain)
>  Description: patch-2.4.10-pre13-sysrq_register

Yep, that certainly fixes the API when CONFIG_MAGIC_SYSRQ
is not defined, which is what I wanted to see.

~Randy