Modules in 2.5.47-bk...
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]
Quoted 10 lines · Petr Vandrovec
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:
Quoted 10 lines
Quoted 8 lines · Petr Vandrovec
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 3 lines
/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.
Quoted 24 lines · Rusty Russell
In message <[email protected]> you write:
Quoted 6 lines
Quoted 3 lines · Petr Vandrovec
Hi Rusty,
I'm probably missing something important, but do you have any plans
to integrate module-init-tools into modutils, or extendmodule-init-tools
Quoted 5 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 8 lines
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.
Quoted 10 lines
Quoted 3 lines
/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:
Quoted 6 lines
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?
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 4 lines
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.
Quoted 7 lines · Rusty Russell
Quoted 5 lines
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.
Quoted 8 lines · Thierry Vignaud
Quoted 6 lines · Rusty Russell
Quoted 5 lines
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...
Quoted 4 lines
Quoted 1 line
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
Signature · 4 lines
"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 SeedQuoted 13 lines · Adrian Bunk
Quoted 11 lines · Thierry Vignaud
Quoted 7 lines · Rusty Russell
Quoted 5 lines
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?
Quoted 7 lines
Quoted 2 lines
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
Quoted 4 lines · Rusty Russell
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.
In message <[email protected]> you write:
Quoted 7 lines · Rusty Russell
Quoted 4 lines
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.