From: Ingo Molnar <mingo@elte.hu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
T?r?k Edwin <edwintorok@gmail.com>,
srostedt@redhat.com, a.p.zijlstra@chello.nl,
sandmann@daimi.au.dk, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Identify which executable object the userspace address belongs to. Store thread group leader id, and use it to lookup the address in the process's map. We could have looked up the address on thread's map, but the thread might not exist by the time we are called. The process might not exist either, but if you are reading trace_pipe, that is unlikely.
Date: Thu, 6 Nov 2008 16:32:38 +0100 [thread overview]
Message-ID: <20081106153238.GD1644@elte.hu> (raw)
In-Reply-To: <20081106122650.GA23474@infradead.org>
* Christoph Hellwig <hch@infradead.org> wrote:
> On Thu, Nov 06, 2008 at 10:55:47AM +0100, Ingo Molnar wrote:
> > > On Mon, Nov 03, 2008 at 08:32:57AM +0100, Ingo Molnar wrote:
> > > > could you please help out with such a helper? This is really about
> > > > visualization, not to rely on it.
> > >
> > > Is this kindergarten? [...]
> >
> > No, this is lkml where, if you decide to stand in the way of a patch,
> > you are supposed to back up your NAK's with a path out of that NAK.
> > Instead of forcing people into multiple email ping-pongs trying to
> > figure out what exactly the objections mean.
>
> Even if that was true, which would be avery sad world I should be
> easy enough for you or anyone to look at what seq_path does and how
> to have a version that doesn't use the seq_file insterface. Takes
> about two minutes with most of the time spent on finding where
> seq_file is implemented.
the timeline i quoted shows that it was a 2 days process, not 2
minutes.
It's the basic principle of communication: be forgiving in what you
receive and conservative in what you transmit. Plus if one extra
sentence of seemingly redundant information increases the chances to
save an email-roundtrip down the line then please do it to increase
communication efficiency and reduce latency.
Just to show you an example, let me give you an analogous situation in
scheduler talk, as a reply to someone from another field who tries to
use an existing scheduler API the wrong way:
"
Hey, you loser, NAK. Sync wakeups are the wrong thing to do, why
dont you just disable buddy wakeups for a minute in sched.c??
[ Only two minutes to write a patch. The solution is really
obvious to me, and we are not in the kindergarten to explain
everything to you. And besides, the longer i make it for you to
figure it all out, the cooler i can feel about being an
ueber-capable scheduler hacker ;-) ]
"
do you want such a world? i dont ;-)
Ingo
next prev parent reply other threads:[~2008-11-06 15:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-02 21:18 Add support for userspace stacktraces in tracing/iter_ctrl [v2] Török Edwin
2008-11-02 21:18 ` [PATCH] Add support for userspace stacktraces in tracing/iter_ctrl Török Edwin
2008-11-02 21:18 ` [PATCH] Identify which executable object the userspace address belongs to. Store thread group leader id, and use it to lookup the address in the process's map. We could have looked up the address on thread's map, but the thread might not exist by the time we are called. The process might not exist either, but if you are reading trace_pipe, that is unlikely Török Edwin
2008-11-02 21:25 ` Al Viro
2008-11-02 21:28 ` Török Edwin
2008-11-02 21:40 ` Al Viro
2008-11-03 7:32 ` Ingo Molnar
2008-11-04 18:26 ` Christoph Hellwig
2008-11-04 18:37 ` Török Edwin
2008-11-04 19:09 ` Christoph Hellwig
2008-11-04 19:10 ` Török Edwin
2008-11-06 9:55 ` Ingo Molnar
2008-11-06 12:26 ` Christoph Hellwig
2008-11-06 15:32 ` Ingo Molnar [this message]
2008-11-06 15:36 ` Christoph Hellwig
2008-11-03 7:47 ` Ingo Molnar
2008-11-03 8:16 ` Török Edwin
2008-11-03 8:21 ` Ingo Molnar
2008-11-03 8:29 ` Ingo Molnar
2008-11-03 13:57 ` Török Edwin
2008-11-03 14:04 ` Ingo Molnar
2008-11-03 19:26 ` Mathieu Desnoyers
2008-11-03 19:56 ` Peter Zijlstra
2008-11-03 19:58 ` Arnaldo Carvalho de Melo
2008-11-03 20:01 ` Török Edwin
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=20081106153238.GD1644@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=edwintorok@gmail.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandmann@daimi.au.dk \
--cc=srostedt@redhat.com \
--cc=viro@ZenIV.linux.org.uk \
/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