2002-09-06 08:26:49

by Juan M. de la Torre

[permalink] [raw]
Subject: Little bug in O(1) scheduler patch (also in 2.4.19-ac4)


Hi,

a module compiled for kernel 2.4.19-ac4, with CONFIG_MODVERSIONS, and
importing flush_signals() from kernel, fails to load, reporting
"unresolved symbol flush_signals_xxxxxxxx".

The problem is that the type of the argument passed to flush_signals()
has been changed from "struct task_struct *" to "task_t *" in sched.h,
but it remains unchanged in kernel/signal.c. The same happens with
flush_signal_handlers().

Sorry if this is a known issue.

Regargs,
Juanma

PS: First sent to Ingo Molnar, since no response, reposting here again.

--
/jm


2002-09-06 08:58:14

by Ingo Molnar

[permalink] [raw]
Subject: Re: Little bug in O(1) scheduler patch (also in 2.4.19-ac4)


On Fri, 6 Sep 2002, Juan M. de la Torre wrote:

> a module compiled for kernel 2.4.19-ac4, with CONFIG_MODVERSIONS, and
> importing flush_signals() from kernel, fails to load, reporting
> "unresolved symbol flush_signals_xxxxxxxx".

what module?

> The problem is that the type of the argument passed to flush_signals()
> has been changed from "struct task_struct *" to "task_t *" in sched.h,
> but it remains unchanged in kernel/signal.c. The same happens with
> flush_signal_handlers().

hm, struct task_struct * is the same as task_t *.

Ingo

2002-09-06 10:13:24

by Juan M. de la Torre

[permalink] [raw]
Subject: Re: Little bug in O(1) scheduler patch (also in 2.4.19-ac4)


I was wrong; the problem i was experimenting was due to a symbolic link
problem (i was compiling the module with other kernel headers). Since
the CRC of a versioned symbol is based on the function arguments i
thought that the different type of the argument (well, is the same type with
different name) has something to do with the error i was getting.

I apologize for wasting readers' time.

Regards,
Juanma

--
/jm