[lkml]   [2001]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] link failur in Linux 2.4.9-ac16 around apm.o and sysrq.o
++ 27/09/01 22:47 -0700 -
> >>>>> "JNH" == junio <> 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 <>
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.052 / U:3.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site