[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel module package depending on kernel-headers.



On Thu, Sep 19, 2002 at 03:31:57PM +0200, Tore Anderson wrote:
> Ian Zimmerman <itz@speakeasy.org> writes:
> 
> > Manoj> And you can set up your module postinst to install the module
> > Manoj> in any directory you want -- /lib/modules/2.4/foo, for example,
> > Manoj> and copy files at will.
> 
> There is no need to copy them. See below.
> 
> > Ian> But what is the point of having them in a package, then?
> > 
> > Manoj> Heh. I have 2.4.17 installed, and I install module_foo. Where
> > Manoj> do the module files go?
> > 
> > Manoj> I now install 2.4.18. Now, either the module search path is
> > Manoj> changed, or boom! no more module foo with new kernel.
> 
> Again, you are mistaken. Only parts of the search path is changed.
> 
> > Manoj> That is why the packaged module foo should copy files to 2.4.18
> > 
> > No.  That is why they should be _shipped_ by the module package in a
> > more generic place to start with, and the generic place should be on
> > the module search path.  Then you don't need to play postinst moving
> > games, and you actually get the benefits of packaging (like, dpkg -L
> > module_foo actually prints where the files are).
> 
> You are right. Modutils in Woody supports this, you can easily place
> modules in /lib/modules/2.4/ - and insmod/modprobe/depmod will
> happily use them, if equivalent modules doesn't exist in
> /lib/modules/`uname -r`.
> 
> modprobe's manual page documents this:
> 
>        The idea is that modprobe will look first in the directory
>        containing modules compiled for the current release of the
>        kernel.  If the module is not found there,  modprobe  will
>        look  in  the directory common to the kernel version (e.g.
>        2.0, 2.2).  If the module is still  found,  modprobe  will
>        look  in  the  directory  containing modules for a default
>        release, and so on.
> 
> I think policy should reccomend third-party modules to be installed
> in the the directory common for all kernels with the same minor
> release.

How do you handle the case when the module in question only works with a
subset of the kernels (let say a 2.4.x module will only work ith kernels
later than 2.4.7 or something such ?).

Friendly,

Sven Luther



Reply to: