RE: [Fault-injection-developer] Kernel module's implementation in 2.5.48/2.5.49

[Zhuang, L. <lou...@in...>]

I agree too. :-) But Stanley has reported this problem into LKML.
Unfortunately, nobody else cares about it and nobody else ever tries this
API. No reference in kernel against this API.

> -----Original Message-----
> From: Rusty Lynch [mailto:ru...@li...]
> Sent: Wednesday, November 27, 2002 3:58 AM
> To: Zhuang, Louis; Wang, Stanley; SourceforgeFI mail list (E-mail)
> Subject: Re: [Fault-injection-developer] Kernel module's 
> implementation
> in 2.5.48/2.5.49
> 
> 
> I disagree.  We need to be working on the front lines with the
> rest of the kernel hackers.  If in our development we find
> problems with other subsystems, then we report them and if
> possible supply a patch that fixes the problem.
> 
>     -rustyl
> 
> ----- Original Message -----
> From: "Zhuang, Louis" <lou...@in...>
> To: "Wang, Stanley" <sta...@in...>; "SourceforgeFI mail list
> (E-mail)" <fau...@li...>
> Sent: Tuesday, November 26, 2002 1:58 AM
> Subject: RE: [Fault-injection-developer] Kernel module's 
> implementation in
> 2.5.48/2.5.49
> 
> 
> > According to Stanley's investigation, I'd like to suggest delay our
> porting
> > against new module API until they are stable and compatible 
> enough. -Louis
> >
> >     > -----Original Message-----
> >     > From: Wang, Stanley [mailto:sta...@in...]
> >     > Sent: Tuesday, November 26, 2002 4:40 PM
> >     > To: SourceforgeFI mail list (E-mail)
> >     > Subject: [Fault-injection-developer] Kernel module's
> >     > implementaiton in
> >     > 2.5.48/2.5.49
> >     >
> >     >
> >     > Hello folks,
> >     > The kernel module's implementation has been changed a lot
> >     > since 2.5.48. And
> >     > some of them would
> >     > influence our development work:
> >     > 1. kernel module's name should be specified by defining
> >     > KBUILD_MODNAME
> >     > 2. The in-kernel module loader had been rewrited, the
> >     > modversions.h had been
> >     > eliminated
> >     > 3. The kernel implemented a new mechanism for get/put
> >     > symbols between
> >     > different modules:
> >     > symbol_get(const char*)/symbol_put(const char
> >     > *)/symbol_put_addr(void *).
> >     > These function
> >     > could get/put a symbol that had been exported by another
> >     > kernel module.
> >     > But there is a little bug with them, the following patch
> >     > could fix this bug:
> >     >
> >     >
> >     > diff -Naur -X dontdiff linux-2.5.49/include/linux/module.h
> >     > linux-2.5.49-bugfix/include/linux/module.h
> >     > --- linux-2.5.49/include/linux/module.h 2002-11-26
> >     > 16:06:36.000000000 +0800
> >     > +++ linux-2.5.49-bugfix/include/linux/module.h 2002-11-26
> >     > 16:01:52.000000000 +0800
> >     > @@ -86,7 +86,7 @@
> >     >  /* Get/put a kernel symbol (calls must be symmetric) */
> >     >  void *__symbol_get(const char *symbol);
> >     >  void *__symbol_get_gpl(const char *symbol);
> >     > -#define symbol_get(x) ((typeof(&x))(__symbol_get(#x)))
> >     > +#define symbol_get(x) ((typeof(&x))(__symbol_get(x)))
> >     >
> >     >  /* For every exported symbol, place a struct in the
> >     > __ksymtab section */
> >     >  #define EXPORT_SYMBOL(sym) \
> >     > @@ -166,7 +166,7 @@
> >     >  #ifdef CONFIG_MODULE_UNLOAD
> >     >
> >     >  void __symbol_put(const char *symbol);
> >     > -#define symbol_put(x) __symbol_put(#x)
> >     > +#define symbol_put(x) __symbol_put(x)
> >     >  void symbol_put_addr(void *addr);
> >     >
> >     >  /* We only need protection against local interrupts. */
> >     >
> >     >
> >     >
> >     > 4. You should get a new module utiliy to cooperate with
> >     > 2.5.48/2.5.49
> >     > (from http://ozlabs.org/~rusty/module-init-tools-0.7.tar.gz)
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Get the new Palm Tungsten T
> > handheld. Power & Color in a compact size!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> > _______________________________________________
> > Fault-injection-developer mailing list
> > Fau...@li...
> > 
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
>