Re: [PATCH] link failur in Linux 2.4.9-ac16 around apm.o and sysrq.o

[Crutcher Dunnavant <crutcher@datastacks.com>]

++ 27/09/01 22:47 -0700 - junio@siamese.dhis.twinsun.com:
> >>>>> "JNH" == junio  <junio@siamese.dhis.twinsun.com> writes:
> 
> JNH> 2.4.9-ac16 fails to link with CONFIG_APM=y and
> JNH> CONFIG_MAGIC_SYSRQ=n.  This is because apm.c unconditionally
> JNH> makes calls to functions (__sysrq_lock_table and friends)
> JNH> defined in sysrq.c.
> 
> JNH> I can think of a couple of different approaches to work this
> JNH> around, but is there an established proper way to resolve this
> JNH> kind of dependency in the kernel code?
> 
> The approaches I listed as (1) and (3) in my previous message
> are non solutions, since it will result in a kernel where apm.o
> makes calls into sysrq functions, whose proper operations would
> depend on sysrq.o to have been properly initialized by other
> parts of the kernel, which still think CONFIG_MAGIC_SYSRQ is not
> defined.

This all became an issue when a patch was requested, and created
where people DIDN't want to #ifdef in their modules. I think that
My approach there was hosed, and that we need to go back to the 
stubs in sysrq.h method, but for all exposed symbols. If every
module which wants to use sysrq has to #ifdef things, code gets ugly.

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