All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.