[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