[PATCH] Magic SysRq alternate fix register functions

From: Crutcher Dunnavant (crutcher@datastacks.com)
Date: Fri Sep 21 2001 - 17:36:08 EST


++ 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.

>
> ++ 20/09/01 11:57 -0700 - Randy.Dunlap:
> > Alan Cox wrote:
> > >
> > > > Yeah, I considered that, and it doesn't matter to me whether it
> > > > reports 0 or -1, but it's the data pointer that (mostly) requires
> > > > the #ifdefs, unless the data is always present or a dummy data pointer
> > > > is used.... ?
> > >
> > > #define it to an inline without some arguments ?
> > ~~~~~~~~~~~~~~~~~~
> > I can't get that to work, but someone else may be able to...
> >
> > Here's another version for you to consider.
> >
> > The [un]register_sysrq_key() calls return 0 when CONFIG_MAGIC_SYSRQ
> > is not defined/configured.
> > However, it sacrifices one small data structure of 3 pointers.
> >
> > ~Randy
> > --- linux/arch/i386/kernel/apm.c.org Mon Sep 17 10:15:45 2001
> > +++ linux/arch/i386/kernel/apm.c Thu Sep 20 11:51:25 2001
> > @@ -703,6 +703,8 @@
> > help_msg: "Off",
> > action_msg: "Power Off\n"
> > };
> > +#else
> > +struct sysrq_key_op sysrq_poweroff_op;
> > #endif
> >
> >
> > --- linux/include/linux/sysrq.h.org Mon Sep 17 10:21:07 2001
> > +++ linux/include/linux/sysrq.h Thu Sep 20 11:42:15 2001
> > @@ -87,8 +87,17 @@
> > }
> >
> > #else
> > -#define register_sysrq_key(a,b) do {} while(0)
> > -#define unregister_sysrq_key(a,b) do {} while(0)
> > +
> > +static inline int register_sysrq_key(int key, struct sysrq_key_op *op_p)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline int unregister_sysrq_key(int key, struct sysrq_key_op *op_p)
> > +{
> > + return 0;
> > +}
> > +
> > #endif
> >
> > /* Deferred actions */
>
>
> --
> Crutcher <crutcher@datastacks.com>
> GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
> R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$
> -
> 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/

-- 
Crutcher        <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
    R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$


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