Re: porting driver to 2.6, partly solved

[LGW <large@lilymarleen.de>]

Randy.Dunlap wrote:

>On Wed, 27 Aug 2003 18:15:51 +0200 LGW <large@lilymarleen.de> wrote:
>
>| Alan Cox wrote:
>| 
>| >On Mer, 2003-08-27 at 16:34, LGW wrote:
>| >  
>| >
>| >>The driver is mostly a wrapper around a generic driver released by the 
>| >>manufacturer, and that's written in C++. But it worked like this for the 
>| >>2.4.x kernel series, so I think it has something todo with the new 
>| >>module loader code. Possibly ld misses something when linking the object 
>| >>specific stuff like constructors?
>| >>    
>| >>
>| >
>| >The new module loader is kernel side, it may well not know some of the
>| >C++ specific relocation types. 
>| >
>| To you think it's possible to remove those relocations completely, so 
>| that the whole C++ stuff is linked "without" any more open relocations?
>
>Hopefully Rusty will see this and make some comments on it.
>
>You could try using objdump to look for the item(s) that have this
>relocation type (0).  That might help to see what is causing it.
>
>Or you could modify the module loader to ignore relocation type 0...
>and see what happens.
>  
>
Hm objdump -r snd-echoaudio.ko gives about six records (of course many 
others):
R_386_NONE    *ABS*

I'm not really sure what they refer to. Or, I don't even know. I think 
that the driver uses some system functions and they are linked like 
that, or so? I had a look and R_386_NONE means "no relocation" - so it 
should be safe to ignore them?

Modifying the kernel module loader like

switch (reloc_type) {
...
  case R_386_NONE:
    break;
...
}

did the trick, but this feels like a really really really UGLY trick.

Of course the best thing would be to rewrite the whole stuff, as it is 
more than hacked together, but I don't have time to do so, know. At 
least the soundcard device appears and plays sound now. I'll see what 
time brings.

Thanks for your support,
  Lars