modutils for both redhat kernels and 2.5.x
I've tried to use modutils-2.4.21-4 - which uses the new module loading in 2.5.49 and is backward compatible with 2.4.x. I works fine, except for the redhat kernels.
I realize that nobody said it had to work with a particular distro, just like to know if anybody has a work around.
jay
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
Quoted 6 lines · sean darcy
I've tried to use modutils-2.4.21-4 - which uses the new module loading in 2.5.49 and is backward compatible with 2.4.x. I works fine, except for the redhat kernels.
I realize that nobody said it had to work with a particular distro, just like to know if anybody has a work around.
No, but then again, the module-init-tools don't come anywhere close to the same interface or functionality that exists (and has existed for a good long time, btw) with the modutils.
I would beg and plead with Linus to back that "crap" out of the kernel until such time as it has a snowball's chance of actually working ... anywhere. As it stands, 2.5 is now 100% unusable until modules works again.
Kernel symbol versioning no longer exists. Depmod no longer exists. Modprobe blindly loads a string of modules without even looking to see if it's already loaded. The command line args for modprobe are laughingly few (and none of the ones a redhat system needs to boot are implemented.) We're back to the flat module namespace (that patch of earth is now 100% salt...) And every single object that forms a module will need to be retooled to adhere to the new module API -- this is a brick wall no one needs right now; there are *still* drivers in the tree that haven't been updated to the new DMA interface and that's been pushed for months (years?)
Just when things begin to work, Linus puts on his sadist hat and makes everything stop working again. Aren't we in the midst of a feature/code freeze so the "ship it" label can be slapped on this thing?
--Ricky
In message <[email protected]> yo u write:
Quoted 4 lines
I would beg and plead with Linus to back that "crap" out of the kernel until such time as it has a snowball's chance of actually working ... anywhere. As it stands, 2.5 is now 100% unusable until modules works again.
Funny, other people seem to be using it.
Quoted 1 line
Kernel symbol versioning no longer exists.
That this patch has not yet been merged is crippling your development efforts HOW, exactly? I was clearly mistaken when I thought that this was low priority.
Quoted 1 line
Depmod no longer exists.
This is true. It doesn't need to for 0.7, but it's being reintroduced in 0.8 for speed.
Quoted 2 lines
Modprobe blindly loads a string of modules without even looking to see if it's already loaded.
Yes, this is a bug (and one not reported by anyone, either). Should be fixed in 0.8.
Quoted 2 lines
The command line args for modprobe are laughingly few (and none of the ones a redhat system needs to boot are implemented.)
Really? I don't recall seeing a bug report from you about it. My Debian system boots fine.
Quoted 2 lines
We're back to the flat module namespace (that patch of earth is now 100% salt...)
Um, we always had a flat module namespace. *ALWAYS*. We did put the modules into subdirectories though. Due to Adam Richter's hard work, with 0.8 we can restore this (basically for the benifit of mkinitrd, which I also don't use).
Quoted 2 lines
And every single object that forms a module will need to be retooled to adhere to the new module API
Really? How fascinating. I must admit that I hadn't noticed that.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 4 lines · Rusty Russell
Quoted 1 line
Depmod no longer exists.
This is true. It doesn't need to for 0.7, but it's being reintroduced in 0.8 for speed.
Doesn't it? When I upgraded from 2.5.45 to 2.5.48, and installed module-init-tools-0.7, a whole bunch of modules failed to load automatically, and I ended up with no pcmcia, no network, no af_packet, no loopback device... I had to load them all manually. Also no USB, hence no USB keyboard and mouse, but I haven't tried loading those manually.
I thought it was depmod not working, but I must have been wrong.
So what happened - is there a known problem with module auto-loading at the moment?
cheers,
-- Jamie
Quoted 8 lines · Jamie Lokier
Doesn't it? When I upgraded from 2.5.45 to 2.5.48, and installed module-init-tools-0.7, a whole bunch of modules failed to load automatically, and I ended up with no pcmcia, no network, no
af_packet, no loopback device... I had to load them all manually. Also no USB, hence no USB keyboard and mouse, but I haven't tried loading those manually.
Quoted 4 lines
I thought it was depmod not working, but I must have been wrong.
So what happened - is there a known problem with module auto-loading at the moment?
Yes it is. The hotplug package looks for the modules.*map files to determine which modules to load when the devices show up. As these are not being generated anymore, that's why they are not getting loaded.
thanks,
greg k-h
In message <[email protected]> you write:
Quoted 6 lines
Quoted 4 lines · Rusty Russell
Quoted 1 line
Depmod no longer exists.
This is true. It doesn't need to for 0.7, but it's being reintroduced in 0.8 for speed.
Quoted 6 lines
Doesn't it? When I upgraded from 2.5.45 to 2.5.48, and installed module-init-tools-0.7, a whole bunch of modules failed to load automatically, and I ended up with no pcmcia, no network, no
af_packet, no loopback device... I had to load them all manually. Also no USB, hence no USB keyboard and mouse, but I haven't tried loading those manually.
Probably barfing on unimplemented modprobe options. That's worked around in the (coming) 0.8.
Quoted 4 lines
I thought it was depmod not working, but I must have been wrong.
So what happened - is there a known problem with module auto-loading at the moment?
Should just work. Details?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 10 lines · Jamie Lokier
Quoted 4 lines · Rusty Russell
Quoted 1 line
Depmod no longer exists.
This is true. It doesn't need to for 0.7, but it's being reintroduced in 0.8 for speed.
Doesn't it? When I upgraded from 2.5.45 to 2.5.48, and installed module-init-tools-0.7, a whole bunch of modules failed to load automatically, and I ended up with no pcmcia, no network, no
af_packet, no loopback device...
Having the driver for the root device not load from the initrd kind of sucks as well. Actually I always build the loopback and ramdisk in, I don't want to find out if initrd boot would work without them ;-)
But trying to build a single kernel for multiple configs of hardware is much harder if you can't just roll multiple initrd files from the single compile. I guess you can build every possible driver in, but I'd rather not.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 6 lines · Rusty Russell
Quoted 4 lines
I would beg and plead with Linus to back that "crap" out of the kernel until such time as it has a snowball's chance of actually working ... anywhere. As it stands, 2.5 is now 100% unusable until modules works again.
Funny, other people seem to be using it.
I'm using a fresh redhat 8.0 install. With the standard modutils, nothing loads. With the updated 2.4.22 modutils, again, nothing loads. With module-init-tool 0.7, none of the redhat startup scripts will work because they depend on "modprobe -c"
Quoted 5 lines
Quoted 1 line
Kernel symbol versioning no longer exists.
That this patch has not yet been merged is crippling your development efforts HOW, exactly? I was clearly mistaken when I thought that this was low priority.
Well excuse me if I get more than a little ticked off after seeing people break prefectly functional systems that have been so for years. Did the existing system need replacing? Maybe. Exactly what does a new "in kernel module loader" provide that demands it be included in the kernel right-this-very-minute? What's so important that everything gets broken right at the moment things are supposed to be settling down? (I often wonder if Linus completely skipped source code management class.)
Quoted 4 lines
Quoted 1 line
Depmod no longer exists.
This is true. It doesn't need to for 0.7, but it's being reintroduced in 0.8 for speed.
And along those lines, we don't "need" modules either.
Quoted 5 lines
Quoted 2 lines
Modprobe blindly loads a string of modules without even looking to see if it's already loaded.
Yes, this is a bug (and one not reported by anyone, either). Should be fixed in 0.8.
You call it a bug; I call it a lame oversite.
Quoted 5 lines
Quoted 2 lines
The command line args for modprobe are laughingly few (and none of the ones a redhat system needs to boot are implemented.)
Really? I don't recall seeing a bug report from you about it. My Debian system boots fine.
Read the man page for "modprobe". How much of your version comes anywhere near that? One cannot blindly change the command line interface of an integral tool without knowing they are going to seriously break things.
Quoted 7 lines
Quoted 2 lines
We're back to the flat module namespace (that patch of earth is now 100% salt...)
Um, we always had a flat module namespace. *ALWAYS*. We did put the modules into subdirectories though. Due to Adam Richter's hard work, with 0.8 we can restore this (basically for the benifit of mkinitrd, which I also don't use).
Really. Then why the months of holy wars for and against directories? And at various points throughout history, there have been totally separate modules with the same name.
Quoted 4 lines
Quoted 2 lines
And every single object that forms a module will need to be retooled to adhere to the new module API
Really? How fascinating. I must admit that I hadn't noticed that.
So, are *you* going to go rewrite every single one of those drivers? Don't, for one second, think the original author(s) and/or current maintainer(s) are gonna flock to the "new way". As I pointed out, there are dozens of drivers that still haven't been converted to the new DMA format -- and that's been on the table for a lot longer.
If Linus and company are happy to keep pushing 2.6/3.0/whatever back several more years, then, by all means, keep re-inventing long accepted core components and half integrated them a week after "feature freeze" and "code freeze".
"Introducing, The New Wheel (tm)... 3.2% rounder than any previous wheel."
--Ricky
I too run with Red Hat 8.0. I had to build 2.5.49-ac1 with module loading disabled (I also got some excellent help/clues from Rusty Lynch when it wouldn't link). Because of that I've got a rather large kernel (~1.6meg) sitting in /boot right now. I can run (in X even) with 2.5.49-ac1, but I wouldn't want to do that for long periods of time until I better understand what's going on with the kernel. And brother, am I ever confused. BTW, just to fan the flames even further, I built 49-ac1 with gcc 3.2.1.
----- Original Message -----
From: "Ricky Beam" <[email protected]>
To: "Rusty Russell" <[email protected]>
Cc: <[email protected]>; "Adam J. Richter" <[email protected]>
Sent: Monday, November 25, 2002 11:44 PM
Subject: Re: modutils for both redhat kernels and 2.5.x
Quoted 91 lines · Rusty Russell
Quoted 6 lines
Quoted 4 lines
I would beg and plead with Linus to back that "crap" out of the kernel until such time as it has a snowball's chance of actually working ... anywhere. As it stands, 2.5 is now 100% unusable until modules works again.
Funny, other people seem to be using it.
I'm using a fresh redhat 8.0 install. With the standard modutils, nothing loads. With the updated 2.4.22 modutils, again, nothing loads. With module-init-tool 0.7, none of the redhat startup scripts will work because they depend on "modprobe -c"
Quoted 5 lines
Quoted 1 line
Kernel symbol versioning no longer exists.
That this patch has not yet been merged is crippling your development efforts HOW, exactly? I was clearly mistaken when I thought that this was low priority.
Well excuse me if I get more than a little ticked off after seeing people break prefectly functional systems that have been so for years. Did the existing system need replacing? Maybe. Exactly what does a new "in kernel module loader" provide that demands it be included in the kernel right-this-very-minute? What's so important that everything gets broken right at the moment things are supposed to be settling down? (I often wonder if Linus completely skipped source code management class.)
Quoted 4 lines
Quoted 1 line
Depmod no longer exists.
This is true. It doesn't need to for 0.7, but it's being reintroduced in 0.8 for speed.
And along those lines, we don't "need" modules either.
Quoted 5 lines
Quoted 2 lines
Modprobe blindly loads a string of modules without even looking to see if it's already loaded.
Yes, this is a bug (and one not reported by anyone, either). Should be fixed in 0.8.
You call it a bug; I call it a lame oversite.
Quoted 5 lines
Quoted 2 lines
The command line args for modprobe are laughingly few (and none of the ones a redhat system needs to boot are implemented.)
Really? I don't recall seeing a bug report from you about it. My Debian system boots fine.
Read the man page for "modprobe". How much of your version comes anywhere near that? One cannot blindly change the command line interface of an integral tool without knowing they are going to seriously break things.
Quoted 7 lines
Quoted 2 lines
We're back to the flat module namespace (that patch of earth is now 100% salt...)
Um, we always had a flat module namespace. *ALWAYS*. We did put the modules into subdirectories though. Due to Adam Richter's hard work, with 0.8 we can restore this (basically for the benifit of mkinitrd, which I also don't use).
Really. Then why the months of holy wars for and against directories? And at various points throughout history, there have been totally separate modules with the same name.
Quoted 4 lines
Quoted 2 lines
And every single object that forms a module will need to be retooled to adhere to the new module API
Really? How fascinating. I must admit that I hadn't noticed that.
So, are *you* going to go rewrite every single one of those drivers? Don't, for one second, think the original author(s) and/or current maintainer(s) are gonna flock to the "new way". As I pointed out, there are dozens of drivers that still haven't been converted to the new DMA format -- and that's been on the table for a lot longer.
If Linus and company are happy to keep pushing 2.6/3.0/whatever back several more years, then, by all means, keep re-inventing long accepted core components and half integrated them a week after "feature freeze" and "code freeze".
"Introducing, The New Wheel (tm)... 3.2% rounder than any previous wheel."
--Ricky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
In message <[email protected]> yo u write:
Quoted 4 lines
I'm using a fresh redhat 8.0 install. With the standard modutils, nothing loads. With the updated 2.4.22 modutils, again, nothing loads. With module-init-tool 0.7, none of the redhat startup scripts will work because they depend on "modprobe -c"
That's going to be problematic then. Could you send me an example of how they use modprobe -c?
Quoted 2 lines
Well excuse me if I get more than a little ticked off after seeing people break prefectly functional systems that have been so for years.
I understand your anger, certainly. Naturally I disagree with perfectly functional, but yes, I agree that we have currently taken a step backwards (particularly wrt the userspace tools). That's why I'm working with others to get humpty-dumpty back together again.
Quoted 2 lines
Exactly what does a new "in kernel module loader" provide that demands it be included in the kernel right-this-very-minute?
What does any feature provide? I could list the extensions that this makes possible without breaking userspace again, but I've listed them elsewhere.
Quoted 3 lines
What's so important that everything gets broken right at the moment things are supposed to be settling down? (I often wonder if Linus completely skipped source code management class.)
Linus chose the feature freeze date as the date at which no new patches were to be submitted. He then worked through the backlog (and he told me he wanted everything else out of the way first). Seems fair enough to me.
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Depmod no longer exists.
This is true. It doesn't need to for 0.7, but it's being reintroduced in 0.8 for speed.
And along those lines, we don't "need" modules either.
No, what I'm saying is that up to 0.7 read the modules directly for their dependencies.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Modprobe blindly loads a string of modules without even looking to see if it's already loaded.
Yes, this is a bug (and one not reported by anyone, either). Should be fixed in 0.8.
You call it a bug; I call it a lame oversite.
No, there was a bug in the code which parsed /proc/modules to see if the module was already there.
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
The command line args for modprobe are laughingly few (and none of the ones a redhat system needs to boot are implemented.)
Really? I don't recall seeing a bug report from you about it. My Debian system boots fine.
Read the man page for "modprobe". How much of your version comes anywhere near that? One cannot blindly change the command line interface of an integral tool without knowing they are going to seriously break things.
No need to be insulting. Needless to say, I've read the code, as well. When reimplementing modprobe, would you have me (a) reimplement the entire thing, warts and all, or (b) take the chance to implement only those parts which are still required?
Note that modprobe has grown significantly over time, so some features obsolete other features.
Quoted 6 lines
Quoted 4 lines
Um, we always had a flat module namespace. *ALWAYS*. We did put the modules into subdirectories though. Due to Adam Richter's hard work, with 0.8 we can restore this (basically for the benifit of mkinitrd, which I also don't use).
Really.
Yes, really.
Quoted 1 line
Then why the months of holy wars for and against directories?
Because people like to argue. They'll probably be coming back. 0.8 shouldn't get confused by the presence of directories, so
Quoted 2 lines
And at various points throughout history, there have been totally separate modules with the same name.
And it is, and was, a bug. They're simply not allowed.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
And every single object that forms a module will need to be retooled to adhere to the new module API
Really? How fascinating. I must admit that I hadn't noticed that.
So, are *you* going to go rewrite every single one of those drivers?
You clearly don't understand sarcasm.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Rusty" == Rusty Russell <[email protected]> writes:
The command line args for modprobe are laughingly few (and none of the ones a redhat system needs to boot are implemented.)
Rusty> Really? I don't recall seeing a bug report from you about it. My Rusty> Debian system boots fine.
My Debian system doesn't load the modules anymore. And I have asked this on the mailinglist last week, but nobody seemed to care :-(
I am curious how your Debian system was able to boot without problems. On my system I have configured quite a few modules, and some of them seem to be loaded by hotplug and some by init scripts. All I see is a lot of commandline errors from modprobe, and a lot of messages like
QM_MODULES: Function not implemented
Kees