module mess in -CURRENT
Linus, Rusty,
what the hell is going on with the modules code in 2.5-CURRENT?
Rusty's monsterpatch breaks basically everything (and remember we're in feature freeze!) instead of doing one thing at a time [1], and it is doing three things that are absolutely separate issues.
We had an almost useable 2.5 and now exactly when we're feature freezing and people are expected to test it we break everything?
Linus, please backout that patch until we a) have modutils that support both the new and old code and b) support at least such basic features as parsing modules.conf and supporting parameters.
Rusty, the next time please submit stuff one feature at a time instead of a monster patch that is cool but breaks everything but looks cool.
The inkernel loader, generic boot-time option and your - umm - strange idea of module unload race reduction are absolute separate things.
[1] e.g. kbuild2.5 was rejected due to the must change everything criteria. not that I actually liked the kbuild2.5 design, but this is exactly the same thing.
Quoted 4 lines · Christoph Hellwig
Linus, please backout that patch until we a) have modutils that support both the new and old code and b) support at least such basic features as parsing modules.conf and supporting parameters.
Quite frankly, at this time a backout means that the thing doesn't go in _at_all_.
It came in before the feature freeze, but I decided that instead of having a totally hectic time I woul dmerge stuff that I got before the freeze at my own leisure, but backing it out now would be basically saying it's not going into 2.6.x. And I think it's worth it.
(There are some other patches I'm still thinking about, notably kprobes and posix timers, but other than that my plate is fairly empty froma feature standpoint. And the kexec stuff I want others to test, at least now it's palatable to me).
People who find the current module situation difficult can just compile in the stuff they need for now.
Linus
Quoted 9 lines · Linus Torvalds
Quoted 4 lines · Christoph Hellwig
Linus, please backout that patch until we a) have modutils that support both the new and old code and b) support at least such basic features as parsing modules.conf and supporting parameters.
Quite frankly, at this time a backout means that the thing doesn't go in _at_all_.
Probably. Or just the non-intrusive parts.
Quoted 4 lines
It came in before the feature freeze, but I decided that instead of having a totally hectic time I woul dmerge stuff that I got before the freeze at my own leisure, but backing it out now would be basically saying it's not going into 2.6.x. And I think it's worth it.
I don't think it's a must have and absolutely don't think it's worth breaking about everything at this stage. Please tell me why rusty can't send a large number of non-intrusive patches that do one thing at a time just like everyone else?
Quoted 2 lines · Linus Torvalds
People who find the current module situation difficult can just compile in the stuff they need for now.
That makes driver debugging almost impossible. It also makes building a test kernel set for a lot of boxes impractical. The completely broken unload stuff is going to be a real pig, PCMCIA only works modular and doesn't work now the unloads are all broken. OTOH the module rewrite has some nice features and a combo modutils is going to sort some of the problem out fairly easily.
The biggest need though is documentation so people can actually fix all the drivers for this stuff.
Quoted 5 lines · Alan Cox
That makes driver debugging almost impossible. It also makes building a test kernel set for a lot of boxes impractical. The completely broken unload stuff is going to be a real pig, PCMCIA only works modular and doesn't work now the unloads are all broken.
Yeah, I forgot about the old 16-bit pcmcia crud. Ugh. At least 32-bit cardbus works fine.
Quoted 2 lines
The biggest need though is documentation so people can actually fix all the drivers for this stuff.
I think Al convinced Rusty that most drivers don't need to worry and that Rusty was a bit over-eager (ie sound, much of char, all of block and fs should all be handled by upper layers without the races)
I think Rusty has most of the pieces, but he's apparently flying around the world right now ;)
Linus
In message <[email protected]> you wri te:
Quoted 7 lines
Quoted 3 lines
The biggest need though is documentation so people can actually fix all the drivers for this stuff.
I think Al convinced Rusty that most drivers don't need to worry and that Rusty was a bit over-eager (ie sound, much of char, all of block and fs should all be handled by upper layers without the races)
Not really. The Kernel Summit and an audit of drivers convinced me that changing every driver simply wasn't feasible.
*You* convinced me not to break any driver source code: every time you dropped my patches I went back and implemented another compat macro 8)
Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
In message <[email protected]> you write:
Quoted 6 lines · Linus Torvalds
Quoted 2 lines
People who find the current module situation difficult can just compile in the stuff they need for now.
That makes driver debugging almost impossible. It also makes building a test kernel set for a lot of boxes impractical.
Sorry, I know I've been feeding Linus too slowly, but I've just flown into Spain and I have a tutorial to deliver. I'm solving it my not sleeping, but that doesn't scale.
Quoted 2 lines
The completely broken unload stuff is going to be a real pig, PCMCIA only works modular and doesn't work now the unloads are all broken.
Agreed, that's what "rmmod --force" is for. Patch in the queue, I promise. That gives more breathing room for fixing the "marked unsafe" issue.
Quoted 2 lines
OTOH the module rewrite has some nice features and a combo modutils is going to sort some of the problem out fairly easily.
Patches welcome, of course. I didn't do any work on the modutils once they passed "backwards compat exec works, basic features work".
Trying to test both the entire stack of patches, and just the first three I was sending to Linus, as every tree came out: well, you can tell my testing wasn't thorough enough for .47.
Quoted 2 lines
The biggest need though is documentation so people can actually fix all the drivers for this stuff.
I posted a document previously (again) and it recieved (valid) harsh criticism for being opaque. I'll rework it. Basically, its an expansion of the old try_inc_modcount to be a first-class citizen (hence called try_module_get()). As previously, should be called (successfully!) before calling through a function ptr which might be in a module (ie. most code which exposes a "register_xxx" should use it). Exceptions if that function cannot sleep (and can't be preemped).
Why is PCMCIA broken?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 2 lines · Rusty Russell
Why is PCMCIA broken?
PCMCIA is broken without modules, not broken because of the change (well it gets rather upset about unload fails but thats a seperate matter)
Hi,
Quoted 4 lines · Linus Torvalds
(There are some other patches I'm still thinking about, notably kprobes and posix timers, but other than that my plate is fairly empty froma feature standpoint. And the kexec stuff I want others to test, at least now it's palatable to me).
Linus, please also consider LTT. The benefits might not be immediately visible, but it's great tool to the analyze system behaviour, which can even be used by non kernel hackers. This means as soon normal users start testing 2.5, they're not limited to fuzzy error messages, but they can tell you what actually happens, when the system doesn't "feel" right.
bye, Roman
In message <[email protected]> you write:
Quoted 7 lines
Linus, Rusty,
what the hell is going on with the modules code in 2.5-CURRENT?
Rusty's monsterpatch breaks basically everything (and remember we're in feature freeze!) instead of doing one thing at a time [1], and it is doing three things that are absolutely separate issues.
<sigh>. I did do it one at a time. I replaced the module loading code as stage I.
Quoted 5 lines
We had an almost useable 2.5 and now exactly when we're feature freezing and people are expected to test it we break everything?
Linus, please backout that patch until we a) have modutils that support both the new and old code
It works for me. This is becoming an FAQ, but I thought the code was
obvious: eg. insmod execvp "insmod.old" when it detects an older kernel, and "make install" moves insmod to insmod.old etc. if insmod.old doesn't already exist.
Quoted 2 lines
and b) support at least such basic features as parsing modules.conf and supporting parameters.
I'm sorry if I'm feeding the patches to Linus too slowly for you, but you know where to find them, I've posted the URL often enough. It hasn't even hit a release yet, so I wasn't worried.
I implemented an in-kernel module loader, implemented the linking code for 6 architectures, re-implemented all the module cruft cleanly on top of it, and kept it uptodate through all the changes in Linus' tree.
And you wonder why I held back fleshing out the implementation of modprobe, until (if) the code was in the kernel?
Quoted 2 lines
The inkernel loader, generic boot-time option and your - umm - strange idea of module unload race reduction are absolute separate things.
I rewrote module.c to make it an in-kernel linker so insmod was 20 lines. And you think I should have re-implemented races in the loading and unloading stages too, so I could remove them in a future patch?
What an odd concept!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.