lkml.org 
[lkml]   [2003]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: The disappearing sys_call_table export.
Date

[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/

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