Re: The disappearing sys_call_table export.

Terje Malmedal (terje.malmedal@usit.uio.no)
Thu, 8 May 2003 15:18:29 +0200


[Christoph Hellwig]
> On Thu, May 08, 2003 at 02:25:51PM +0200, Terje Malmedal wrote:
>>
>> EXPORT_SYMBOL_GPL_AND_DONT_EVEN_THINK_ABOUT_SENDING_A_BUG_REPORT(sys_call_table);
>>
>> and displaying a nasty warning message on the console whenever a
>> module used it?

> What about just adding the EXPORT_SYMBOL() yourself yo your kernels
> if you think you need it so badly because you can't screw yourself
> enough without it?

And if I wish to help somebody running a kernel I didn't compile?

Do you have anything constructive to say about situation i referred
to:

A database is starting to run slower and slower, turns out that this
is because fsync() is inefficient on large files. Rebooting the server
or restarting the database is undesirable even at night.

?

I was able to fix this without rebooting or restarting the database.
How do you propose to fix something similar today without having
sys_call_table exported?

Also what exactly is the badness people are complaining about, if I do:

int init_module(void)
{
orig_fsync=sys_call_table[SYS_fsync];
sys_call_table[SYS_fsync]=hacked_fsync;
return 0;
}

void cleanup_module(void)
{
sys_call_table[SYS_fsync]=orig_fsync;
}

The only problem I can see is that different modules overloading the
same function needs to be unloaded in the correct order. Is this the
only reason for removing it, or am I missing something?

-- 
 - Terje
malmedal@usit.uio.no
-
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/