[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131108165233.GA28753@redhat.com>
Date: Fri, 8 Nov 2013 17:52:33 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Namhyung Kim <namhyung.kim@....com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Hyeoncheol Lee <cheol.lee@....com>,
Hemant Kumar <hkshaw@...ux.vnet.ibm.com>,
LKML <linux-kernel@...r.kernel.org>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch
methods (v6)
Hi Namhyung,
sorry for delay.
On 11/07, Namhyung Kim wrote:
>
> >> > As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
> >> > the "@" argument anyway, why it can't also substruct this offset?
> >>
> >> Hmm.. it makes sense too. :)
> >
> > I am no longer sure ;)
> >
> > This way the "@" argument will look more confusing, it will depend on the
> > address/offset of the probed insn. But again, I do not know, this is up
> > to you.
>
> That said, I'd prefer the original "-= -tu->offset" approach. It'll
> make debugging easier IMHO.
I do not really mind, and probably you are right. Actually it seems
that I was confused, if user-space does "-= -tu->offset" itself then
the "@" argument will look more consistent (contrary to what I said
above).
In any case we should make the calculation of "@" argument (in user
space) as simple/clear as possible, it is very easy to add the
additional hacks in kernel if necessary.
And this is very (if not most) important part, we can change the kernel
later, but it is not easy to change the already working semantics, so I'd
like to know what other reviewers think.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists