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
-
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 30 2001 - 21:00:23 EST