[PATCH] Workaround for NFS breakage in 2.5.2pre3

[PATCH] Workaround for NFS breakage in 2.5.2pre3

[Bernhard Rosenkraenzer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 368 bytes --]

depmod: *** Unresolved symbols in /lib/modules/2.5.2-pre3/kernel/fs/nfs/nfs.o
depmod:         seq_escape
depmod:         seq_printf

I'm quite sure the patch I've attached is *not* the right thing to do(tm), 
but it works for me until we get a better fix. ;)

LLaP
bero

-- 
This message is provided to you under the terms outlined at
http://www.bero.org/terms.html



[-- Attachment #2: NFS workaround --]
[-- Type: TEXT/PLAIN, Size: 315 bytes --]

--- linux-2.5/fs/nfs/inode.c.nfsw	Sat Dec 29 16:42:57 2001
+++ linux-2.5/fs/nfs/inode.c	Sat Dec 29 16:33:14 2001
@@ -37,6 +37,8 @@
 #include <asm/system.h>
 #include <asm/uaccess.h>
 
+#include "../seq_file.c"
+
 #define CONFIG_NFS_SNAPSHOT 1
 #define NFSDBG_FACILITY		NFSDBG_VFS
 #define NFS_PARANOIA 1

[PATCH] exporting seq_* stuff

[Alexander Viro]

On Sat, 29 Dec 2001, Bernhard Rosenkraenzer wrote:

> depmod: *** Unresolved symbols in /lib/modules/2.5.2-pre3/kernel/fs/nfs/nfs.o
> depmod:         seq_escape
> depmod:         seq_printf
> 
> I'm quite sure the patch I've attached is *not* the right thing to do(tm), 
> but it works for me until we get a better fix. ;)
> 
> LLaP
> bero

[snip the attached horror]

diff -urN C2-pre3/kernel/ksyms.c C2-pre3-fix/kernel/ksyms.c
--- C2-pre3/kernel/ksyms.c	Thu Dec 27 19:48:04 2001
+++ C2-pre3-fix/kernel/ksyms.c	Sat Dec 29 13:48:12 2001
@@ -46,6 +46,7 @@
 #include <linux/tty.h>
 #include <linux/in6.h>
 #include <linux/completion.h>
+#include <linux/seq_file.h>
 #include <asm/checksum.h>
 
 #if defined(CONFIG_PROC_FS)
@@ -480,6 +481,12 @@
 EXPORT_SYMBOL(reparent_to_init);
 EXPORT_SYMBOL(daemonize);
 EXPORT_SYMBOL(csum_partial); /* for networking and md */
+EXPORT_SYMBOL(seq_escape);
+EXPORT_SYMBOL(seq_printf);
+EXPORT_SYMBOL(seq_open);
+EXPORT_SYMBOL(seq_release);
+EXPORT_SYMBOL(seq_read);
+EXPORT_SYMBOL(seq_lseek);
 
 /* Program loader interfaces */
 EXPORT_SYMBOL(setup_arg_pages);

Re: [PATCH] exporting seq_* stuff

[Andrew Morton]

Alexander Viro wrote:
> 
> [snip the attached horror]

[ replace with a different one :-) ]
 
> diff -urN C2-pre3/kernel/ksyms.c C2-pre3-fix/kernel/ksyms.c
> --- C2-pre3/kernel/ksyms.c      Thu Dec 27 19:48:04 2001
> +++ C2-pre3-fix/kernel/ksyms.c  Sat Dec 29 13:48:12 2001
> @@ -46,6 +46,7 @@
>  #include <linux/tty.h>
>  #include <linux/in6.h>
>  #include <linux/completion.h>
> +#include <linux/seq_file.h>
>  #include <asm/checksum.h>
> 
>  #if defined(CONFIG_PROC_FS)
> @@ -480,6 +481,12 @@
>  EXPORT_SYMBOL(reparent_to_init);
>  EXPORT_SYMBOL(daemonize);
>  EXPORT_SYMBOL(csum_partial); /* for networking and md */
> +EXPORT_SYMBOL(seq_escape);
> +EXPORT_SYMBOL(seq_printf);
> +EXPORT_SYMBOL(seq_open);
> +EXPORT_SYMBOL(seq_release);
> +EXPORT_SYMBOL(seq_read);
> +EXPORT_SYMBOL(seq_lseek);

Personally, I prefer to see the EXPORT_SYMBOL() near the
definition of the thing being exported.  For functions, the
convention I like is:

void foo()
{
}
EXPORT_SYMBOL(foo);

It's nicer, and prevents patch conflicts.

I'd propose that we drop the concept of EXPORT_OBJ by making all
files eligible for exporting symbols, and that the janitors be given
a mandate to scrap the ksyms files.

Is this acceptable?

-

Re: [PATCH] exporting seq_* stuff

[Linus Torvalds]

On Sat, 29 Dec 2001, Andrew Morton wrote:
>
> Personally, I prefer to see the EXPORT_SYMBOL() near the
> definition of the thing being exported.  For functions, the
> convention I like is:

I'd rather have them in the same source-file, but not spread around in the
file. It's nice to see _what_ a file exports, without having to grep for
them.

HOWEVER, putting them in many different source-files makes compilation
slower, so I personally avoid that unless one source-file is clearly
important enough to do so. For core functionality where we clearly export
the functions to the rest of the kernel through a header file anyway, we
might as well keep the EXPORT_SYMBOL's central, and speed up kernel
builds that way.

> I'd propose that we drop the concept of EXPORT_OBJ by making all
> files eligible for exporting symbols, and that the janitors be given
> a mandate to scrap the ksyms files.
>
> Is this acceptable?

No. Check the speed of "make dep" with every single file exporting
objects. Not pretty.

		Linus