Updated parameter and modules rewrite (2.4.14)
PATCH 1/1 Updated parameter and modules rewrite (2.4.14)
Hi all,
http://ftp.kernel.org/pub/linux/kernel/people/rusty
Unified boot/module parameter and module loader rewrite
updated to 2.4.14. I'm off to Linux Kongress, so I'll be difficult to contact for 10 days or so.
Main TODOS:
1) Should the PARAM() macros also declare the variables? Lots of people seem to like writing INT_MODULE_PARM macros...
2) Need a less-sucky /proc|/proc/sys patch, to add access to parameters through that.
Cheers!
Rusty.
--
Premature optmztion is rt of all evl. --DK
Quoted 7 lines · In article <E166p1R-0004ll-00@wagner> you wrote:
Hi all,
http://ftp.kernel.org/pub/linux/kernel/people/rusty
Unified boot/module parameter and module loader rewrite
updated to 2.4.14. I'm off to Linux Kongress, so I'll be difficult to contact for 10 days or so.
I absolutly oppose to the cosmetic naming changes.
Please let module be be initialized by module_init() and exited by module_exit(). We had a hard enough time to get it everywhere, not to mention the name makes a lot of sense.
Also MODULE_PARAM should just stay, combined with Keith's proposal to use it at boottime aswell (as KBUILD_OBJECT.<paramname>).
Christoph
Signature · 1 line
Of course it doesn't work. We've performed a software upgrade.
In message <[email protected]> you write:
Quoted 8 lines
Quoted 5 lines · In article <E166p1R-0004ll-00@wagner> you wrote:
http://ftp.kernel.org/pub/linux/kernel/people/rusty
Unified boot/module parameter and module loader rewrite
updated to 2.4.14. I'm off to Linux Kongress, so I'll be difficult to contact for 10 days or so.I absolutly oppose to the cosmetic naming changes.
Hi Christoph!
Um, me too. I should have reposted my previous explanation, sorry!
Quoted 3 lines
Please let module be be initialized by
module_init()and exited bymodule_exit(). We had a hard enough time to get it everywhere, not to mention the name makes a lot of sense.
Unfortunately, removal needs to be done in two stages, to sanely make things like IPv6 modular (a deactivate, and a kill stage). It turns out that this applies to loading as well, in case the loading fails part way through (there's also a number of modules at the moment which initialize in the wrong order, which can lead to an oops).
Quoted 2 lines
Also
MODULE_PARAMshould just stay, combined with Keith's proposal to use it at boottime aswell (as KBUILD_OBJECT.<paramname>).
Firstly, Keith and I agree on KBUILD_OBJECT[/.]paramname, BTW. I'm not sure it was his proposal originally, though: it's a pretty simple and old idea.
The previous module param stuff was prone to user bugs (no type checking), was not extensible, and required duplicated code for boot time. It also did not have the option of appearing in /proc.
It is possible to write macros mapping the NEW macros to the OLD, but not vice versa, otherwise I wouldn't change at all.
Hope that clarifies,
Rusty.
--
Premature optmztion is rt of all evl. --DK
Quoted 9 lines · Rusty Russell
Hi all,
http://ftp.kernel.org/pub/linux/kernel/people/rusty
Unified boot/module parameter and module loader rewrite
updated to 2.4.14. I'm off to Linux Kongress, so I'll be difficult to contact for 10 days or so.
Quoted 6 lines
Main TODOS:
1) Should thePARAM()macros also declare the variables? Lots of people seem to like writingINT_MODULE_PARMmacros...2) Need a less-sucky /proc|/proc/sys patch, to add access to parameters through that.
I did have a look at it and I would like to express my full encouragements
to yours efforts. Finally somebody out there caring about modularization of the kernel, who doesn't continuously introduce sick stuff like...
We remember:
1. Highjacking System V IPC for autoloader communication.
2. "Persistant module storage" patches, which destabilize the kernel.
3. inter_module* idiocy.
4. Overloaded system calls.