From: Rusty Russell <rusty@rustcorp.com.au>
To: davidm@hpl.hp.com
Cc: Mike Stephens <mike.stephens@intel.com>,
linux-kernel@vger.kernel.org, bjornw@axis.com,
geert@linux-m68k.org, ralf@gnu.org, mkp@mkp.net,
willy@debian.org, anton@samba.org, gniibe@m17n.org,
kkojima@rr.iij4u.or.jp, Jeff Dike <jdike@karaya.com>
Subject: Re: Userspace Test Framework for module loader porting
Date: Mon, 13 Jan 2003 11:27:21 +1100 [thread overview]
Message-ID: <20030113011128.76CDC2C052@lists.samba.org> (raw)
In-Reply-To: Your message of "Fri, 10 Jan 2003 17:47:20 -0800." <15903.30632.576801.904652@napali.hpl.hp.com>
In message <15903.30632.576801.904652@napali.hpl.hp.com> you write:
> >>>>> On Wed, 08 Jan 2003 22:44:15 +1100, Rusty Russell <rusty@rustcorp.com.a
u> said:
> Yeah, I'm lazy: I don't really want to have to deal with two new
> module loaders: one for 2.6, soon to be followed by one for 2.7. But
> if someone volunteers to do and _maintain_ an interim kernel loader,
> that's fine with me.
Well, "soon" here is > 12 months away, of course. And most of it
involves removing, rather than adding, code.
> Rusty> I thought about letting archs choose which one they wanted to
> Rusty> use, but it would really mess up the core code. Of course,
> Rusty> the transition won't break userspace (kind of the whole point
> Rusty> of the in-kernel module loader).
>
> But it would be more in keeping with the Linux philosophy: do the
> Right Thing, fix up "broken" stuff by doing whatever is necessary.
I think you missed the "work around what we can't change" (eg. always
initializing per-cpu variables because Sparc's toolchain is broken, or
adding that crazy restart stuff so we didn't have to create a one-arg
re-enterable nanosleep then make glibc use it).
And, of course, the other Golden Rule: "if it's not x86, it doesn't
matter" 8)
> I'm also a bit worried about changing module loaders so often. Yeah,
> once you switch to a kernel-loader, presumably users won't be
> affected, but (kernel-module) developers will be.
While ET_DYN modules are a reasonably serious win for ia64 (and
probably hppa) (ie. -300 lines or so), they're a minor win for alpha
and ppc64 (-100 lines or so), and no real change for arm, i386, ppc,
sparc, and sparc64. It's a lose for x86_64 (toolchain fixes, unless
they want to use -fPIC for modules), mips and mips64 (major toolchain
fixes, unless they want to use -fPIC for modules and stop using r28
for current inside modules).
So, if I were ia64 maintainer, I'd be lobbying for ET_DYN modules now,
too, but I don't it's a big enough general win to outweigh the other
problems.
Sorry,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2003-01-13 1:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-06 2:27 Userspace Test Framework for module loader porting Rusty Russell
2003-01-06 19:38 ` David Mosberger
2003-01-06 22:41 ` Richard Henderson
2003-01-07 0:37 ` David Mosberger
2003-01-08 11:44 ` Rusty Russell
2003-01-11 1:47 ` David Mosberger
2003-01-13 0:27 ` Rusty Russell [this message]
2003-01-13 13:20 ` Maciej W. Rozycki
2003-01-14 0:01 ` Rusty Russell
2003-01-24 18:23 ` return-type for search_extable() David Mosberger
2003-01-28 4:53 ` Rusty Russell
2003-01-28 6:14 ` David Mosberger
2003-01-08 11:21 ` Userspace Test Framework for module loader porting 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=20030113011128.76CDC2C052@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=anton@samba.org \
--cc=bjornw@axis.com \
--cc=davidm@hpl.hp.com \
--cc=geert@linux-m68k.org \
--cc=gniibe@m17n.org \
--cc=jdike@karaya.com \
--cc=kkojima@rr.iij4u.or.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=mike.stephens@intel.com \
--cc=mkp@mkp.net \
--cc=ralf@gnu.org \
--cc=willy@debian.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