Re: Modules in 2.5.47-bk...

From: Jeff Garzik (
Date: Wed Nov 13 2002 - 23:06:42 EST

Rusty Russell wrote:

> In message <> you write:
> >Petr Vandrovec wrote:
> >
> >
> >>Hi Rusty,
> >> I'm probably missing something important, but do you have any plans
> >>to integrate module-init-tools into modutils, or extend
> module-init-tools
> >>functionality to make them usable? I tried module-init-tools 0.6
> >>and I must say that I'm really surprised that it is possible to make
> >>such change after feature freeze, without maintaining at least minimal
> >>usability.
> >>
> >> If there are modutils which can live with new module system, please
> >>point me to them. But I did not found such.
> >
> >
> >I'm hoping that Rusty will work with Keith to integrate support for
> >2.5.x into the existing modutils package... it's rather annoying to
> >have two totally different modutils when switching between 2.[024].x and
> >2.5.x kernels.
> The current method is that on "make install" the module-init-tools
> move the old ones to xxx.old (if they exist), and do a backwards
> compat check every time they start (and execvp xxx.old on every older
> kernel). If it doesn't work for you, please report.
> To package them, the distros will probably hack modutils into
> module-init-tools/old or something and make them install themselves as
> xxx.old automatically. Code apprediated.

That's what I meant about working with existing modutils. I can't think
that anybody is excited about the extra work involved in supporting two
modutils packages for years to come.

The backward compat thing is really a hack, and not system software done
right :( modutils should not need to rename all its binaries *.old --
and have that be the default that users see when installing the rpm. No
company worth its shareholders would release a package full of "*.old"
binaries. Come on...

If its politics that is preventing you from submitting modutils
packages, then I encourage you to publicly post modutils patches, so
that the early adopters, distros, and others can use those and have
their existing systems continue to work seamlessly between 2.4 and 2.5.

foo.old is not a solution we want with us long-term... and booting into
older kernels will be with us long-term.

> >/me is building drivers into the kernel for now, which slows down
> >debugging, because modules are broken on ia32 and module support isn't
> >present on alpha at all anymore [AFAICS]...
> Yes, I've been distracted, sorry. I only implemented i386, ia64,
> sparc, sparc64, ppc and ppc64 (some untested in-kernel, but linking
> logic works). I have access to an Alpha, but work has stopped while I
> try to keep up with everything else. RTH can probably complete it in
> a fraction of the time I could anyway.

Well, that more than satisfies my objection here, then. Thanks. I only
saw ia32 modifications go into the kernel... I'm glad others have been
tested, or at least played with, on multiple architectures. I'm sure if
rth doesn't tackle alpha module loading, Ivan or I will have it done :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:32 EST