From: Rusty Russell <rusty@rustcorp.com.au>
To: John Levon <levon@movementarian.org>
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [PATCH] Add module load profile hook
Date: Tue, 25 Feb 2003 19:07:41 +1100 [thread overview]
Message-ID: <20030225112211.9A8142C247@lists.samba.org> (raw)
In-Reply-To: Your message of "Tue, 25 Feb 2003 02:58:52 -0000." <20030225025852.GB49589@compsoc.man.ac.uk>
In message <20030225025852.GB49589@compsoc.man.ac.uk> you write:
> On Tue, Feb 25, 2003 at 12:25:23PM +1100, Rusty Russell wrote:
> > That would be because that was a HACK, and it's my job to say "no",
> > even when that means we're not "feature complete" by someone's
> > definition.
>
> You've yet to explain why it's a hack as opposed to a reasonable level
> of discoverability. This includes your comments on IRC where you agreed
> I had a point.
You're still mistaking politeness for agreement. Of course you have a
point: there *is* benefit in being able to tell where modules are
without changing any code, otherwise you wouldn't be asking for it.
But it's not going to happen.
It's the bit where you add it a "store this filename" and "get the
filename" kernel which makes no sense whatsoever: the kernel has no
need for the information, why should it hold it?
Making modprobe store this somewhere kind of makes sense, but since
the algorithm that modprobe uses to map names to filenames is trivial,
I'm not convinced that the complexity is sensible (unless you want to
handle special cases like module renaming with -o).
Making insmod store this information, since insmod is supposed to be
the dumb workhorse util (ie. "use modprobe") doesn't make as much
sense. But this is exactly the tool that kernel hackers are likely to
use when they want fine control over their own modules (ie. likely to
be used with oprofile).
The way that gdb solves this is to have a path directive, where you
can say "look here for source". Or you could send me a patch for
modprobe to put the information somewhere sensible if you prefer that.
What makes most sense to you?
> > You seem to have taken the politeness of my previous response as an
> > indication of uncertainty.
>
> I took your point and agreed to translate into whatever you like.
And you took a pot-shot at me for being inconsistent: did you expect
me not to clarify?
> I'm not a kernel hacker and I don't particularly give a shit ...
Huh? You sent a patch. If you don't care, noone will.
Confused,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
prev parent reply other threads:[~2003-02-25 11:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-20 21:53 [PATCH] Add module load profile hook John Levon
2003-02-21 0:33 ` Rusty Russell
2003-02-21 0:54 ` John Levon
2003-02-24 0:33 ` Rusty Russell
2003-02-24 17:16 ` John Levon
2003-02-25 1:25 ` Rusty Russell
2003-02-25 2:58 ` John Levon
2003-02-25 8:07 ` Rusty Russell [this message]
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=20030225112211.9A8142C247@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=levon@movementarian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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