From: Rusty Russell <rusty@rustcorp.com.au>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] automatic module_init ordering
Date: Tue, 06 Aug 2002 17:28:14 +1000 [thread overview]
Message-ID: <20020806073804.2E30F4BA3@lists.samba.org> (raw)
In-Reply-To: Your message of "Mon, 05 Aug 2002 21:05:13 +0200." <3D4ECC69.F0084A2C@linux-m68k.org>
In message <3D4ECC69.F0084A2C@linux-m68k.org> you write:
> Are you sure sent the right patch? This one misses a few changes.
> Anyway, I stole all the good ideas and integrated them into my patch. :)
Great, I was hoping you'd do that!
> - I use a separate initcall for the module initialization, that's the
> only way I can solve my IDE problems.
That's horrible 8( I think we need figure out why this is happening:
do you know? What does it actually need?
Ahh, I just came across the same problem! See my
ordered-core-initcalls patch, for bio.c changes: you probably need to
change this too (and I deleted the redundany explicit IDE inits).
> - I put the initcall for that directly into the generated file.
> - raid autodetect became a late_initcall()
Icky, but that's what my follow-on patch for explicit initcalls is
for. So raid is an example where it doesn't have an implicit
dependency, but it does have an actual dependency.
> - I don't use trap to clean up, so people can send us the temporary
> files, if something should go wrong. These files will be removed by a
> normal 'make clean' anyway.
Hmmm... Good idea, at least for the moment. Eventually we won't have
any bugs 8)
I've updated my explicit core initcalls patch on top of your new one,
thanks!
http://www.kernel.org/pub/linux/kernel/people/rusty/Misc/ordered-core-initcalls.patch.2.5.30.gz
It reverts your module initcall change, and boots here.
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2002-08-06 7:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-01 23:52 Roman Zippel
2002-08-02 3:19 ` Kai Germaschewski
2002-08-02 21:22 ` Sam Ravnborg
2002-08-03 1:17 ` Kai Germaschewski
2002-08-03 22:11 ` Sam Ravnborg
2002-08-04 15:30 ` Roman Zippel
2002-08-04 20:04 ` Sam Ravnborg
2002-08-04 20:10 ` Sam Ravnborg
2002-08-05 6:13 ` Rusty Russell
2002-08-05 19:05 ` Roman Zippel
2002-08-06 7:28 ` Rusty Russell [this message]
2002-08-06 18:57 ` Roman Zippel
2002-08-07 1:05 ` Rusty Russell
2002-08-07 2:28 ` Kai Germaschewski
2002-08-07 10:40 ` Roman Zippel
2002-08-07 11:10 ` Rusty Russell
-- strict thread matches above, loose matches on Subject: below --
2002-07-29 23:46 [PATCH] automatic initcalls Rusty Russell
2002-07-30 23:04 ` [PATCH] automatic module_init ordering Roman Zippel
2002-07-31 2:33 ` Kai Germaschewski
2002-07-31 3:26 ` Rusty Russell
2002-07-31 17:06 ` Kai Germaschewski
2002-07-31 23:28 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020806073804.2E30F4BA3@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®