++ 27/09/01 22:47 -0700 - email@example.com:
> >>>>> "JNH" == junio <firstname.lastname@example.org> 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
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 <email@example.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 firstname.lastname@example.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:01:03 EST