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.
For now I gave up. Except other, I did not found way how to pass
options to module: MODULE_PARM() is now always nothing, and
while options are probably stored in THIS_MODULE->args, I see
no users of this (load_module finds .setup.init (which is now named
.init.setup, and __setup expands to it only ifndef MODULE, BTW!), but
ignores it afterward).
So in short, is there available some document which says why this
change was needed, where it is going, and what fs and device driver
developers (ie. me) should do to get their (ie. mine) drivers back
to working state? Should I just concentrate on my other projects,
and stop tracking 2.5.x kernels? Or should I just do couple of
cset -x ?
Thanks,
Petr Vandrovec
[email protected]
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.
/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]...
In message <[email protected]> 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.
> /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.
Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Rusty Russell wrote:
> In message <[email protected]> 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.
Please?
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 :)
Jeff
In message <[email protected]> you write:
> Rusty Russell wrote:
> 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...
OK, would calling it "*-2.4" or something help?
> foo.old is not a solution we want with us long-term... and booting into
> older kernels will be with us long-term.
Execing the older binary is a good way to make a clean break in the
source. It means we can keep separate maintainers and not worry about
syncing issues, too (Keith has said he doesn't want to maintain
modules in 2.5, fair enough)
There are other ways to do the same thing, bu this seemed simplest.
> Well, that more than satisfies my objection here, then. Thanks.
Sorry if I was a bit sharp. I've been surprised by the "I'm going to
have to abandon 2.5 kernel development now" reaction. Some people
seem upset that I didn't respond to mail for 12 hours 8( I also
haven't spoken to my wife for over 48 hours because I've been on the
modem in my hotel room every time she's been awake.
> 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 :)
Unfortunately the Alpha ELF spec is in RTH's head. I have a userspace
framework I can send you (faster than debugging linking inside the
kernel) which you can hack for Alpha.
To see what's coming, look for the "Modules" section:
http://www.kernel.org/pub/linux/kernel/people/rusty
Thanks,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
On Thu, Nov 14, 2002 at 02:53:50PM +1100, Rusty Russell wrote:
> 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.
Which breaks nicely every package manager database.
Rusty Russell <[email protected]> writes:
> > 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...
>
> OK, would calling it "*-2.4" or something help?
most distros come with some alternative system (at lest, debian, mdk &
rh), so this problem can legally be left to vendors.
In message <[email protected]> you write:
> On Thu, Nov 14, 2002 at 02:53:50PM +1100, Rusty Russell wrote:
> > 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.
>
> Which breaks nicely every package manager database.
Yes. So don't package it like that if you care about backwards
compatibility.
The entire point is that the new code is simple enough that you can
quite simply fix it. And indeed, someone already has, while you were
whining.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
On Thu, Nov 14, 2002 at 04:45:16PM +0100, Thierry Vignaud wrote:
> Rusty Russell <[email protected]> writes:
>
> > > 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...
> >
> > OK, would calling it "*-2.4" or something help?
>
> most distros come with some alternative system (at lest, debian, mdk &
> rh), so this problem can legally be left to vendors.
The alternative system doesn't work in this case because it doesn't help
you when you want to switch between 2.4 and 2.6 kernels. You need some
kind of wrapper.
The code that does
if kernel < 2.5.x
if xxx-2.4 exists
run xxx-2.4
else
error: no xxx-2.4
fi
else
do_something
fi
should be included in the new modutils.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
> On Thu, Nov 14, 2002 at 04:45:16PM +0100, Thierry Vignaud wrote:
>
> >Rusty Russell writes:
> >
> >
> >>>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...
> >>
> >>OK, would calling it "*-2.4" or something help?
> >
> >most distros come with some alternative system (at lest, debian, mdk &
> >rh), so this problem can legally be left to vendors.
>
>
> The alternative system doesn't work in this case because it doesn't help
> you when you want to switch between 2.4 and 2.6 kernels. You need some
> kind of wrapper.
Agreed. The alternatives stuff I am familiar with does not changes
symlinks based on the version of booted kernel, AFAIK.
Jeff