Special place for tird-party modules.

Special place for tird-party modules.

[Goran Cengic]

Hi all,

The other day I installed some newly compiled modules with "make 
modules_install" from the source three and that action removed already 
installed nvidia kernel module so I had to rebuild and install it again.

This leads to following question:

I know that kernel can be compiled so that it cant load different versions of 
the modules (it says so in the help text of the kernel configuration). How 
come then there is no special place, say /lib/modules/local, for third-party 
modules so that they can be installed just by copying them there from the 
distribution archive and doing whatever configuration needed from there on? 

This way hardware vendors could just compile the module and distribute it in 
the binary form. This would also make it easy to upgrade the kernel without 
having to reinstall all the drivers. What are arguments for and against this 
approach? Why does the nvidia driver have to be compiled for different kernel 
versions? Can't they make one module that fits all kernels?

Another question is, if there is a way to compile kernel that loads modules of 
different versions, why are the modules still installed in 
"/lib/modules/`uname -r`/*" instead of "/lib/modules/*" by default? In another 
words. Why is it necessary to upgrade modules with every kerenel release even 
though some of them might not be in the need there of?

I do understand that many developers have several kernel version installed at 
the same time but is it possible to share between the versions at least the 
modules that are not developed as the part of the kernel?

If I'm missing something cruical please point it out to me.

Thanks in advance.

/Goran

mailto:cengic@s2.chalmers.se
Have a nice day :)

Re: Special place for tird-party modules.

[Goran Cengic]

On Wednesday 28 April 2004 18.35, Bartlomiej Zolnierkiewicz wrote:
> Hey, we already have a special place for binary only modules.
>
> It is called /dev/null. 8)

:)

>
> > against this approach? Why does the nvidia driver have to be compiled for
> > different kernel versions? Can't they make one module that fits all
> > kernels?
>
> No, it was discussed zillion times already.

Where can I find the discussion? Was it on this list?

>
> > If I'm missing something cruical please point it out to me.
>
> You are missing fact that module compiled for specific kernel version
> may not work with another kernel version. ;-)

Ok, but why is there possibility to ignore version number of the modules if it 
makes no sense?

>
> Cheers,
> Bartlomiej

/Goran

Goran Cengic
mailto:cengic@s2.chalmers.se
------------------------------
Have a nice day :)

Re: Special place for tird-party modules.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

On Wed, 28 Apr 2004 19:05:45 +0200, Goran Cengic <cengic@s2.chalmers.se>  said:

> > You are missing fact that module compiled for specific kernel version
> > may not work with another kernel version. ;-)
> 
> Ok, but why is there possibility to ignore version number of the modules if it 
> makes no sense?

The Linux Way is to allow you to discharge firearms - making sure they aren't
pointed at your feet is your own problem.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Special place for tird-party modules.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On Wed, 28 Apr 2004 18:14:24 +0200, Goran Cengic <cengic@s2.chalmers.se>  said:

> I do understand that many developers have several kernel version installed at
> the same time but is it possible to share between the versions at least the 
> modules that are not developed as the part of the kernel?
> 
> If I'm missing something cruical please point it out to me.

What you're missing is the reason for modversions to exist - the fact that the
kernel API *does* change between releases, and even within the same source tree
(UP vs SMP builds, for instance).  If we supported what you're suggesting, then
the following *will* happen:

1) Binary module for 2.6.N is released that uses an API that takes 5 parameters.
2) 2.6.N+1 comes out, and said API has another parameter added (see the recent
tweak-fest for elf_map() for an actual example).
3) User loads old binary into kernel.
4) Kernel OOPs when it dereferences the non-existent 6th parameter that wasn't
passed by the un-updated binary.



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Special place for tird-party modules.

[Goran Cengic]

On Wednesday 28 April 2004 21.18, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 28 Apr 2004 18:14:24 +0200, Goran Cengic <cengic@s2.chalmers.se>  
said:
> > I do understand that many developers have several kernel version
> > installed at the same time but is it possible to share between the
> > versions at least the modules that are not developed as the part of the
> > kernel?
> >
> > If I'm missing something cruical please point it out to me.
>
> What you're missing is the reason for modversions to exist - the fact that
> the kernel API *does* change between releases, and even within the same
> source tree (UP vs SMP builds, for instance).  If we supported what you're
> suggesting, then the following *will* happen:
>
> 1) Binary module for 2.6.N is released that uses an API that takes 5
> parameters. 2) 2.6.N+1 comes out, and said API has another parameter added
> (see the recent tweak-fest for elf_map() for an actual example).
> 3) User loads old binary into kernel.
> 4) Kernel OOPs when it dereferences the non-existent 6th parameter that
> wasn't passed by the un-updated binary.

Ok, I get it :) Thank you!

/Goran

----------------------------------
Goran Cengic
mailto:cengic@s2.chalmers.se
----------------------------------
Have a nice day :)