porting driver to 2.6, still unknown relocs... :(

porting driver to 2.6, still unknown relocs... :(

[LGW]

Hi again.

As I described before, I try to port an audio driver from 2.4.x to 2.6.x.

It compiles, but on load I get "module snd_echoaudio: Unknown 
relocation: 0" from dmesg.

I looked into arch/*/kernel/module.c, and this error appears if the 
loaded module contains a relocation other than R_386_32 or R_386_PC32 
(for intel).

Now I wonder, what would be an relocation type 0? The printk should also 
print the type in clear text I think, but it just prints 0. 0 also does 
not look very much like a valid value at all, or does it?

These are the commands used to build the modules (taken from the .*.cmd 
files):

// for the main module file:
gcc -Wp,-MD,sound/pci/echoaudio/.echoaudio.o.d -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe 
-mpreferred-stack-boundary=2 -march=athlon 
-Iinclude/asm-i386/mach-default -D__KERNEL__ -Iinclude  -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=athlon 
-Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include -DMODULE 
-I/usr/include -Isound/pci/echoaudio/DSP -Isound/pci/echoaudio/ASIC 
-DGINA_20 -DECHO_LINUX -DECHOGALS_FAMILY  -DKBUILD_BASENAME=echoaudio 
-DKBUILD_MODNAME=snd_echoaudio -c
-o sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/echoaudio.c

// for the c++ helper files:
g++ -fno-rtti -Wall -Wstrict-prototypes -Wno-trigraphs -O2 
-fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon 
-Iinclude/asm-i386/mach-default -D__KERNEL__ -Iinclude  -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -nostdinc 
-iwithprefix include -DMODULE -Isound/pci/echoaudio/DSP 
-Isound/pci/echoaudio/ASIC -DGINA_20 -DECHO_LINUX -DECHOGALS_FAMILY  
-DKBUILD_BASENAME=echoaudio -DKBUILD_MODNAME=snd_echoaudio 
-I/usr/include -o $@.o $@.cpp

// linking echoaudio.o
ld -m elf_i386  -r -o sound/pci/echoaudio/snd-echoaudio.o 
sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/OsSupportLinux.o 
sound/pci/echoaudio/CDaffyDuck.o sound/pci/echoaudio/CEchoGals_info.o
sound/pci/echoaudio/CEchoGals_transport.o 
sound/pci/echoaudio/CPipeOutCtrl.o sound/pci/echoaudio/CEchoGals_mixer.o 
sound/pci/echoaudio/CMidiInQ.o sound/pci/echoaudio/CEchoGals_midi.o 
sound/pci/echoaudio/CEchoGals_power.o sound/pci/echoaudio/CEchoGals.o 
sound/pci/echoaudio/CLineLevel.o sound/pci/echoaudio/CMonitorCtrlL.o 
sound/pci/echoaudio/CChannelMask.o 
sound/pci/echoaudio/CGdDspCommObject.o 
sound/pci/echoaudio/CDspCommObject.o 
sound/pci/echoaudio/CGinaDspCommObject.o sound/pci/echoaudio/CGina.o

// linking snd-echoaudio.o
ld -m elf_i386  -r -o sound/pci/echoaudio/snd-echoaudio.o 
sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/OsSupportLinux.o 
sound/pci/echoaudio/CDaffyDuck.o sound/pci/echoaudio/CEchoGals_info.o
sound/pci/echoaudio/CEchoGals_transport.o 
sound/pci/echoaudio/CPipeOutCtrl.o sound/pci/echoaudio/CEchoGals_mixer.o 
sound/pci/echoaudio/CMidiInQ.o sound/pci/echoaudio/CEchoGals_midi.o 
sound/pci/echoaudio/CEchoGals_power.o sound/pci/echoaudio/CEchoGals.o 
sound/pci/echoaudio/CLineLevel.o sound/pci/echoaudio/CMonitorCtrlL.o 
sound/pci/echoaudio/CChannelMask.o 
sound/pci/echoaudio/CGdDspCommObject.o 
sound/pci/echoaudio/CDspCommObject.o 
sound/pci/echoaudio/CGinaDspCommObject.o sound/pci/echoaudio/CGina.o

// linking snd-echoaudio.ko
ld -m elf_i386 -r -o sound/pci/echoaudio/snd-echoaudio.ko 
sound/pci/echoaudio/snd-echoaudio.o sound/pci/echoaudio/snd-echoaudio.mod.o

I have no idea why those commands should lead to a file with broken 
relocations. Please help me...

thanks,
  Lars

Re: porting driver to 2.6, still unknown relocs... :(

[Randy.Dunlap]

On Wed, 27 Aug 2003 15:38:26 +0200 LGW <large@lilymarleen.de> wrote:

| Hi again.
| 
| As I described before, I try to port an audio driver from 2.4.x to 2.6.x.
| 
| It compiles, but on load I get "module snd_echoaudio: Unknown 
| relocation: 0" from dmesg.
| 
| I looked into arch/*/kernel/module.c, and this error appears if the 
| loaded module contains a relocation other than R_386_32 or R_386_PC32 
| (for intel).
| 
| Now I wonder, what would be an relocation type 0? The printk should also 
| print the type in clear text I think, but it just prints 0. 0 also does 
| not look very much like a valid value at all, or does it?

Maybe g++ generates something different?
Are parts of your driver in c++?

| These are the commands used to build the modules (taken from the .*.cmd 
| files):
| 
| // for the main module file:
| gcc -Wp,-MD,sound/pci/echoaudio/.echoaudio.o.d -Wall -Wstrict-prototypes 
| -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe 
| -mpreferred-stack-boundary=2 -march=athlon 
| -Iinclude/asm-i386/mach-default -D__KERNEL__ -Iinclude  -Wall 
| -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
| -pipe -mpreferred-stack-boundary=2 -march=athlon 
| -Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include -DMODULE 
| -I/usr/include -Isound/pci/echoaudio/DSP -Isound/pci/echoaudio/ASIC 
| -DGINA_20 -DECHO_LINUX -DECHOGALS_FAMILY  -DKBUILD_BASENAME=echoaudio 
| -DKBUILD_MODNAME=snd_echoaudio -c
| -o sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/echoaudio.c
| 
| // for the c++ helper files:
| g++ -fno-rtti -Wall -Wstrict-prototypes -Wno-trigraphs -O2 
| -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon 
| -Iinclude/asm-i386/mach-default -D__KERNEL__ -Iinclude  -Wall 
| -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -nostdinc 
| -iwithprefix include -DMODULE -Isound/pci/echoaudio/DSP 
| -Isound/pci/echoaudio/ASIC -DGINA_20 -DECHO_LINUX -DECHOGALS_FAMILY  
| -DKBUILD_BASENAME=echoaudio -DKBUILD_MODNAME=snd_echoaudio 
| -I/usr/include -o $@.o $@.cpp
| 
| // linking echoaudio.o
| ld -m elf_i386  -r -o sound/pci/echoaudio/snd-echoaudio.o 
| sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/OsSupportLinux.o 
| sound/pci/echoaudio/CDaffyDuck.o sound/pci/echoaudio/CEchoGals_info.o
| sound/pci/echoaudio/CEchoGals_transport.o 
| sound/pci/echoaudio/CPipeOutCtrl.o sound/pci/echoaudio/CEchoGals_mixer.o 
| sound/pci/echoaudio/CMidiInQ.o sound/pci/echoaudio/CEchoGals_midi.o 
| sound/pci/echoaudio/CEchoGals_power.o sound/pci/echoaudio/CEchoGals.o 
| sound/pci/echoaudio/CLineLevel.o sound/pci/echoaudio/CMonitorCtrlL.o 
| sound/pci/echoaudio/CChannelMask.o 
| sound/pci/echoaudio/CGdDspCommObject.o 
| sound/pci/echoaudio/CDspCommObject.o 
| sound/pci/echoaudio/CGinaDspCommObject.o sound/pci/echoaudio/CGina.o
| 
| // linking snd-echoaudio.o
| ld -m elf_i386  -r -o sound/pci/echoaudio/snd-echoaudio.o 
| sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/OsSupportLinux.o 
| sound/pci/echoaudio/CDaffyDuck.o sound/pci/echoaudio/CEchoGals_info.o
| sound/pci/echoaudio/CEchoGals_transport.o 
| sound/pci/echoaudio/CPipeOutCtrl.o sound/pci/echoaudio/CEchoGals_mixer.o 
| sound/pci/echoaudio/CMidiInQ.o sound/pci/echoaudio/CEchoGals_midi.o 
| sound/pci/echoaudio/CEchoGals_power.o sound/pci/echoaudio/CEchoGals.o 
| sound/pci/echoaudio/CLineLevel.o sound/pci/echoaudio/CMonitorCtrlL.o 
| sound/pci/echoaudio/CChannelMask.o 
| sound/pci/echoaudio/CGdDspCommObject.o 
| sound/pci/echoaudio/CDspCommObject.o 
| sound/pci/echoaudio/CGinaDspCommObject.o sound/pci/echoaudio/CGina.o
| 
| // linking snd-echoaudio.ko
| ld -m elf_i386 -r -o sound/pci/echoaudio/snd-echoaudio.ko 
| sound/pci/echoaudio/snd-echoaudio.o sound/pci/echoaudio/snd-echoaudio.mod.o
| 
| I have no idea why those commands should lead to a file with broken 
| relocations. Please help me...


--
~Randy

Re: porting driver to 2.6, still unknown relocs... :(

[LGW]

Randy.Dunlap wrote:

>On Wed, 27 Aug 2003 15:38:26 +0200 LGW <large@lilymarleen.de> wrote:
>
>| Now I wonder, what would be an relocation type 0? The printk should also 
>| print the type in clear text I think, but it just prints 0. 0 also does 
>| not look very much like a valid value at all, or does it?
>
>Maybe g++ generates something different?
>Are parts of your driver in c++?
>
I think the g++ is the problem, but I'm not sure what it is.

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?

I don't think there are any other errors in the module (like 
incompatible MODULE_stuff or missing statements), as it has been copied 
from a patched alsa-0.9.6, and I diff'd the other drivers, not finding 
much differences (if any).

Any ld parameters I could try? I already tried -Ur, but that lead to 
nothing :(

thanks,
  Lars

>| // for the c++ helper files:
>| g++ -fno-rtti -Wall -Wstrict-prototypes -Wno-trigraphs -O2 
>| -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon 
>| -Iinclude/asm-i386/mach-default -D__KERNEL__ -Iinclude  -Wall 
>| -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -nostdinc 
>| -iwithprefix include -DMODULE -Isound/pci/echoaudio/DSP 
>| -Isound/pci/echoaudio/ASIC -DGINA_20 -DECHO_LINUX -DECHOGALS_FAMILY  
>| -DKBUILD_BASENAME=echoaudio -DKBUILD_MODNAME=snd_echoaudio 
>| -I/usr/include -o $@.o $@.cpp
>| 
>| // linking echoaudio.o
>| ld -m elf_i386  -r -o sound/pci/echoaudio/snd-echoaudio.o 
>| sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/OsSupportLinux.o 
>| sound/pci/echoaudio/CDaffyDuck.o sound/pci/echoaudio/CEchoGals_info.o
>| sound/pci/echoaudio/CEchoGals_transport.o 
>| sound/pci/echoaudio/CPipeOutCtrl.o sound/pci/echoaudio/CEchoGals_mixer.o 
>| sound/pci/echoaudio/CMidiInQ.o sound/pci/echoaudio/CEchoGals_midi.o 
>| sound/pci/echoaudio/CEchoGals_power.o sound/pci/echoaudio/CEchoGals.o 
>| sound/pci/echoaudio/CLineLevel.o sound/pci/echoaudio/CMonitorCtrlL.o 
>| sound/pci/echoaudio/CChannelMask.o 
>| sound/pci/echoaudio/CGdDspCommObject.o 
>| sound/pci/echoaudio/CDspCommObject.o 
>| sound/pci/echoaudio/CGinaDspCommObject.o sound/pci/echoaudio/CGina.o
>| 
>| // linking snd-echoaudio.o
>| ld -m elf_i386  -r -o sound/pci/echoaudio/snd-echoaudio.o 
>| sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/OsSupportLinux.o 
>| sound/pci/echoaudio/CDaffyDuck.o sound/pci/echoaudio/CEchoGals_info.o
>| sound/pci/echoaudio/CEchoGals_transport.o 
>| sound/pci/echoaudio/CPipeOutCtrl.o sound/pci/echoaudio/CEchoGals_mixer.o 
>| sound/pci/echoaudio/CMidiInQ.o sound/pci/echoaudio/CEchoGals_midi.o 
>| sound/pci/echoaudio/CEchoGals_power.o sound/pci/echoaudio/CEchoGals.o 
>| sound/pci/echoaudio/CLineLevel.o sound/pci/echoaudio/CMonitorCtrlL.o 
>| sound/pci/echoaudio/CChannelMask.o 
>| sound/pci/echoaudio/CGdDspCommObject.o 
>| sound/pci/echoaudio/CDspCommObject.o 
>| sound/pci/echoaudio/CGinaDspCommObject.o sound/pci/echoaudio/CGina.o
>| 
>| // linking snd-echoaudio.ko
>| ld -m elf_i386 -r -o sound/pci/echoaudio/snd-echoaudio.ko 
>| sound/pci/echoaudio/snd-echoaudio.o sound/pci/echoaudio/snd-echoaudio.mod.o
>  
>

Re: porting driver to 2.6, still unknown relocs... :(

[Randy.Dunlap]

On Wed, 27 Aug 2003 17:34:29 +0200 LGW <large@lilymarleen.de> wrote:

| Randy.Dunlap wrote:
| 
| >On Wed, 27 Aug 2003 15:38:26 +0200 LGW <large@lilymarleen.de> wrote:
| >
| >| Now I wonder, what would be an relocation type 0? The printk should also 
| >| print the type in clear text I think, but it just prints 0. 0 also does 
| >| not look very much like a valid value at all, or does it?

In 2.6.0, include/asm-i386/elf.h lists the ELF relocation types.
Type 0 is "R_386_NONE".  Apparently something is being generated
with "no relocation needed" if I interpret this correctly (?).

| >Maybe g++ generates something different?
| >Are parts of your driver in c++?
| >
| I think the g++ is the problem, but I'm not sure what it is.
| 
| 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?

Maybe.  It probably wasn't meant to support C++.

Is the generic driver source code available?

| I don't think there are any other errors in the module (like 
| incompatible MODULE_stuff or missing statements), as it has been copied 
| from a patched alsa-0.9.6, and I diff'd the other drivers, not finding 
| much differences (if any).
| 
| Any ld parameters I could try? I already tried -Ur, but that lead to 
| nothing :(

--
~Randy

Re: porting driver to 2.6, still unknown relocs... :(

[Alan Cox]

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. 

Re: porting driver to 2.6, still unknown relocs... :(

[LGW]

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?

After all, those are only "helper functions" that could be linked 
"statically", or am I mistaken?

I don't have such deep knowledge of the C++ linking process, so I can't 
answer that question myself.

The Generic Driver is not public available I think, but you could get it 
here:
http://space.virgilio.it/g_pochini@virgilio.it/ea.html (site with the 
patches for alsa)
http://space.virgilio.it/g_pochini@virgilio.it/eagd-0.6.0.tar.bz2 (the 
original generic driver code)

thanks,
  Lars

Re: porting driver to 2.6, still unknown relocs... :(

[Randy.Dunlap]

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.

| After all, those are only "helper functions" that could be linked 
| "statically", or am I mistaken?
| 
| I don't have such deep knowledge of the C++ linking process, so I can't 
| answer that question myself.
| 
| The Generic Driver is not public available I think, but you could get it 
| here:
| http://space.virgilio.it/g_pochini@virgilio.it/ea.html (site with the 
| patches for alsa)
| http://space.virgilio.it/g_pochini@virgilio.it/eagd-0.6.0.tar.bz2 (the 
| original generic driver code)

--
~Randy

Re: porting driver to 2.6, partly solved

[LGW]

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

Re: porting driver to 2.6, still unknown relocs... :(

[Stephen Hemminger]

On 27 Aug 2003 16:59:38 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> 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. 

You did something that was explicitly not supported on 2.4 and it worked,
it broke on 2.6.

The fact that it worked it all on 2.4 was a fluke.

It's time to breakdown, do the right thing and figure out how to rewrite/translate the
C++ code to C.

Re: porting driver to 2.6, still unknown relocs... :(

[Richard B. Johnson]

On Wed, 27 Aug 2003, Stephen Hemminger wrote:

> On 27 Aug 2003 16:59:38 +0100
> Alan Cox <alan@lxorguk.ukuu.org.uk> 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.
>
> You did something that was explicitly not supported on 2.4 and it worked,
> it broke on 2.6.
>
> The fact that it worked it all on 2.4 was a fluke.
>
> It's time to breakdown, do the right thing and figure out how to rewrite/translate the
> C++ code to C.
>

> You did something that was explicitly not supported on 2.4 and it worked,
                             ^^^^^^^^^^^^^^^^^^^^^^^^_______ Yes!

There was lots of discussion/flames back-and-forth with newbies
requiring that modules be written in C++.  This is what you get.
Some of the C++ built-ins are not even global so the linker
won't be able to find them if they are used. It's not just
a matter of emulating 'new'. Parameter-passing 'by reference' also
won't work so putting 'C' wrappers around stuff like they do
in Dr. Jobbs and C/C++ Journal isn't going to work inside
the kernel where there is no support.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: porting driver to 2.6, still unknown relocs... :(

[LGW]

Richard B. Johnson wrote:

>On Wed, 27 Aug 2003, Stephen Hemminger wrote:
>
>  
>
>>On 27 Aug 2003 16:59:38 +0100
>>Alan Cox <alan@lxorguk.ukuu.org.uk> 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.
>>>      
>>>
>>You did something that was explicitly not supported on 2.4 and it worked,
>>it broke on 2.6.
>>
>>The fact that it worked it all on 2.4 was a fluke.
>>
>>It's time to breakdown, do the right thing and figure out how to rewrite/translate the
>>C++ code to C.
>>
>>    
>>
>
>  
>
>>You did something that was explicitly not supported on 2.4 and it worked,
>>    
>>
>                             ^^^^^^^^^^^^^^^^^^^^^^^^_______ Yes!
>
>There was lots of discussion/flames back-and-forth with newbies
>requiring that modules be written in C++.  This is what you get.
>Some of the C++ built-ins are not even global so the linker
>won't be able to find them if they are used. It's not just
>a matter of emulating 'new'. Parameter-passing 'by reference' also
>won't work so putting 'C' wrappers around stuff like they do
>in Dr. Jobbs and C/C++ Journal isn't going to work inside
>the kernel where there is no support.
>  
>
I absolutly agree with your opinion here. But due to the fact that the 
driver sources from the manufacturer where c++, a wrapper was easier 
(and the license of the driver is... restrictive I'm afraid...). But a 
rewrite in C is only a matter of time!

anyway, I have sound again, that's enough for the next few weeks I think.

regards,
  Lars