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

Re: /lib/modules/kabi-4.0-0*



On Thu, 16 Mar 2006, Björn Augustsson wrote:

> On Thu, Mar 16, 2006 at 11:05:27AM -0500, Jason Baron wrote:
> > On Thu, 16 Mar 2006, Björn Augustsson wrote:
> > 
> > > I haven't found any docs on this, and as far as I can deduce from a
> > > running system, neither module-init-tools not mkinitrd knows anything
> > > about the kabi directories.
> > > 
> > > Anyone?
> > 
> > 3rd party modules that are compiled against any of the kernel-devel pkgs 
> > should continue to work fine against any later kernels without having to 
> > re-compile. If this is not the case for, we want to know about it. We have 
> > a number of practices in place to make sure that this works.
> 
> I'm sorry, I don't get it.
> 
> But normally a module will end up somewhere in /lib/modules/`uname -r`
> and the next kernel will not look there. So what am I supposed to do? 
> 
> * Move it to the /lib/modules/kabi-xyz dir?
> * Move it to the /lib/modules/<new-kernel> dir?
> 
> or what?
> 
> Is the module supposed to know about this, and install itself to 
> the kabi dir? What if it doesn't?
> 
> /August, man of many questions.
> 

as you noticed, i avoided that part of your question :) We've really left 
this procedure up to 3rd party vendors, to decide where, and how they want 
to manage their own modules. To me, this is almost to a fault....i think 
the orginal idea behind the /lib/modules/kabi* directory was in fact that 
modules should be stuck in there so that they could be treated in a 
generic way. The kernel could export its own 'kabi' version and then all 
the tools, 'depmod', 'mkinitrd', etc. could know about that path. However, 
as you pointed out that work was really never fleshed out. ie the tools 
don't know about the path. I'd be interested in making this happen, if 
people think its a good idea...

thanks.

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