[gobolinux-devel] Kernel packages, module packages and kernel matching

Ricardo Nabinger Sanchez rnsanchez at wait4.org
Sat Nov 25 23:33:04 UTC 2006


On Fri, 24 Nov 2006 21:18:14 +0100
"Jonas Karlsson" <jonka750 at student.liu.se> wrote:

> > Moreover, it could be a version window.  For instance, there are some  
> > funky
> > drivers that were released for 2.X.XX, and as long as they work, a new  
> > one is
> > not released.
> >
> Problem is that the modules need to be compilefor the exact kernel version  
> as they check that and fail to load unless the versions of the running  
> kernel and the kernel sources used to compile the kernel match.

Only if the kernel is compiled to check/enable module versioning, IIRC.
Although I believe enabling module versioning is default nowadays (and should
provide safer operation).

> > I believe this would only require slightly different kernel  
> > configurations,
> > for different i686 CPUs (and, why not, amd64 even using a x86-32 base
> > system?).
> >
> > The drawback is that this may create weird arch-specific bug reports.   
> > But you
> > can always blame Lucas! :)
> >
> Yes, blame Lucas ;)
> To be honest I don't think we could handle multiple architechtures. I mean  
> we don't even do it unoficially now, how should we have time to do it  
> officially?

Of course, time-consuming was missing, but it is a major issue like you
pointed out.  But on the other hand, it would be somewhat a matter of kernel
config maintainers, just like Recipes.  I mean, Lucas keeps linux-2.6.xx-arm,
Hisham linux-2.6.xx-ppc, and others the arch of their use/choice.
Derivatives of a main generic kernel configuration (basically the same except
for the arch).

Sounds feasible?  I feeling too optimistic with this, probably I'm missing
something obvious here.

-- 
Ricardo Nabinger Sanchez     <rnsanchez@{gmail.com,wait4.org}>
Powered by FreeBSD

  "Left to themselves, things tend to go from bad to worse."


More information about the gobolinux-devel mailing list