modutils for both redhat kernels and 2.5.x

modutils for both redhat kernels and 2.5.x

[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.

jay




_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

Re: modutils for both redhat kernels and 2.5.x

[Ricky Beam]

On Sun, 24 Nov 2002, sean darcy wrote:
>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

Re: modutils for both redhat kernels and 2.5.x

[Rusty Russell]

In message <Pine.GSO.4.33.0211251830050.6708-100000@sweetums.bluetronic.net> yo
u write:
> 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.

> 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.

> 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.

> 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.

> 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.

> 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).

> 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.

Re: modutils for both redhat kernels and 2.5.x

[Jamie Lokier]

Rusty Russell wrote:
> > 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

Re: modutils for both redhat kernels and 2.5.x

[Greg KH]

On Tue, Nov 26, 2002 at 02:11:00AM +0000, Jamie Lokier wrote:
> 
> 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?

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

Re: modutils for both redhat kernels and 2.5.x

[Rusty Russell]

In message <20021126021100.GB29814@bjl1.asuk.net> you write:
> Rusty Russell wrote:
> > > 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.

Probably barfing on unimplemented modprobe options.  That's worked
around in the (coming) 0.8.

> 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.

Re: modutils for both redhat kernels and 2.5.x

[Bill Davidsen]

On Tue, 26 Nov 2002, Jamie Lokier wrote:

> Rusty Russell wrote:
> > > 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.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: modutils for both redhat kernels and 2.5.x

[Ricky Beam]

On Tue, 26 Nov 2002, Rusty Russell wrote:
>> 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"

>> 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.)

>> 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.

>> 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.

>> 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.

>> 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.

>> 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

Re: modutils for both redhat kernels and 2.5.x

[Bill Beebe]

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" <jfbeam@bluetronic.net>
To: "Rusty Russell" <rusty@rustcorp.com.au>
Cc: <linux-kernel@vger.kernel.org>; "Adam J. Richter"
<adam@freya.yggdrasil.com>
Sent: Monday, November 25, 2002 11:44 PM
Subject: Re: modutils for both redhat kernels and 2.5.x


> On Tue, 26 Nov 2002, Rusty Russell wrote:
> >> 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"
>
> >> 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.)
>
> >> 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.
>
> >> 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.
>
> >> 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.
>
> >> 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.
>
> >> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: modutils for both redhat kernels and 2.5.x

[Rusty Russell]

In message <Pine.GSO.4.33.0211252320530.6708-100000@sweetums.bluetronic.net> yo
u write:
> 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?

> 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.

> 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.

> 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.

> >> 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.

> >> 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.

> >> 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.

> >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.

> 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

> 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.

> >> 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.

Re: modutils for both redhat kernels and 2.5.x

[Kees Bakker]

>>>>> "Rusty" == Rusty Russell <rusty@rustcorp.com.au> 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

Re: modutils for both redhat kernels and 2.5.x

[sean darcy]

OK.OK So there's no way to boot both.

FWIW, modutils-2.4.21-4 works fine with built 2.4.19 and 2.4.20-rc3 kernels. 
While modprobe -c does give errors, all the rh scripts seem to work fine.

AND, rh's position on all this:

"You need *entirely different* modutils, not just a new modutils. We 
probably
won't be looking into this until the new 2.5 module loader is actually 
finished" Bugzilla 78508

So if you want to try 2.5 kernels, make your own 2.4.x, you can't use the rh 
kernels.











_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: modutils for both redhat kernels and 2.5.x

[Stephen Rothwell]

Hi,

On Tue, 26 Nov 2002 22:22:22 -0500 "sean darcy" <seandarcy@hotmail.com> wrote:
>
> OK.OK So there's no way to boot both.
> 
> FWIW, modutils-2.4.21-4 works fine with built 2.4.19 and 2.4.20-rc3 kernels. 
> While modprobe -c does give errors, all the rh scripts seem to work fine.
> 
> AND, rh's position on all this:
> 
> "You need *entirely different* modutils, not just a new modutils. We 
> probably
> won't be looking into this until the new 2.5 module loader is actually 
> finished" Bugzilla 78508
> 
> So if you want to try 2.5 kernels, make your own 2.4.x, you can't use the rh 
> kernels.

Rusty has available a source RPM just for this situation.

http://www.kernel.org/pub/linux/kernel/people/rusty/modules/modutils-2.4.21-4.src.rpm

Download this, build the rpm and install it and you will have both the new
and old available to you ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/