> I do have a really large objection of merging the current messy double
> ptrace implementation. If current utrace based ptrace isn't 100% ready
> there's absolutely no point in merging it.
There is no "current" utrace-ptrace implementation. I haven't proposed
one for merging. When one is re
On Tue, Mar 31, 2009 at 11:17:42AM +0200, Peter Zijlstra wrote:
> > Could those who object to utrace please pipe up and summarise their
> > reasons?
>
> Christoph used to have an opinion on this matter, so I've added him to
> the CC.
I've never objected utrace per see, quite contrary I think it's
Hi -
On Tue, Mar 31, 2009 at 11:17:42AM +0200, Peter Zijlstra wrote:
> [...] Right, from my POV something like utrace is desirable, since
> its basically a huge multiplexer for the debugger state, eventually
> allowing us to have multiple debuggers attached to the same process.
> [...]
Right.
On Tue, 2009-03-31 at 11:17 +0200, Peter Zijlstra wrote:
> On Mon, 2009-03-30 at 15:18 -0700, Andrew Morton wrote:
> > So we need to work out what to do about utrace and I feel a need to hit
> > the reset button on all this. Largely because I've forgotten
> > everything and it was all confusing an
On Mon, 2009-03-30 at 15:18 -0700, Andrew Morton wrote:
> So we need to work out what to do about utrace and I feel a need to hit
> the reset button on all this. Largely because I've forgotten
> everything and it was all confusing anyway.
Right, from my POV something like utrace is desirable, sin
Hi -
On Mon, Mar 30, 2009 at 03:18:44PM -0700, Andrew Morton wrote:
> So we need to work out what to do about utrace and I feel a need to hit
> the reset button on all this. [...]
Thanks.
> [...] The ftrace patch merged about as (un)successfully as one would
A new version against -tip is comi
So we need to work out what to do about utrace and I feel a need to hit
the reset button on all this. Largely because I've forgotten
everything and it was all confusing anyway.
Could those who object to utrace please pipe up and summarise their
reasons?
Just to kick the can down the road a bit
On Mon, Mar 23, 2009 at 10:54:09PM -0700, Andrew Morton wrote:
> On Tue, 24 Mar 2009 10:59:26 +0530 Ananth N Mavinakayanahalli
> wrote:
>
> > On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> > > On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler"
> > > wrote:
> > > > On Sat,
On Tue, 24 Mar 2009 10:59:26 +0530 Ananth N Mavinakayanahalli
wrote:
> On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> > On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler"
> > wrote:
> > > On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> >
> > I have strong
On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" wrote:
> > On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
>
> I have strong memories of being traumatised by reading the uprobes code.
That was a long time ago
On Mon, Mar 23, 2009 at 04:14:00PM +0100, Oleg Nesterov wrote:
>
> Yes, ptrace-over-utrace needs more work. But your message looks as if
> utrace core is buggy, imho this is a bit unfair ;)
>
> As Roland said, ptrace-over-utrace is not ready yet. If you mean that
> utrace core should not be merge
On Mon, 23 Mar 2009, Frank Ch. Eigler wrote:
> > I have CONFIG_DEBUG_INFO turned off in 99.9% of my kernel builds,
> > because it slows down the kernel build times significantly: [...]
>
> OK, 15% longer time.
It's way more than that if you don't have tons of memory and excessive
amounts of C
Hi -
On Sun, Mar 22, 2009 at 01:08:11PM +0100, Ingo Molnar wrote:
> [...]
> > In my own limited kernel-building experience, I find the debuginfo
> > data conveniently and instantly available after every "make". Can
> > you elaborate how is it harder for you to incidentally make it
> > than for
On 03/23, Alexey Dobriyan wrote:
>
> Right now with ptrace(2) rewrite the following is easily triggerable:
>
> WARNING: at kernel/ptrace.c:515 ptrace_report_signal+0x2c1/0x2d0()
Yes, ptrace-over-utrace needs more work. But your message looks as if
utrace core is buggy, imho this is a bit unfair ;)
Denys Vlasenko writes:
> [...]
>> Here's the /debugfs/tracing/process_trace_README:
>> process event tracer mini-HOWTO [...]
>
> A HOWTO text in the kernel binary? Shouldn't it be in
> Documentation/* instead? [...]
It parallels the debugfs/tracing/README file.
- FChE
On Sun, Mar 22, 2009 at 01:37:49PM +0100, Ingo Molnar wrote:
> The ptrace bits and signoffs from Oleg and Alexey would certainly
> help (me) in trusting it. (I've Cc:-ed Oleg and Alexey)
The further utrace stays away from mainline, the better.
That's from my experience with this code.
But let's
On Fri, 2009-03-20 at 18:42 -0700, Roland McGrath wrote:
> From: Frank Ch. Eigler
> Here's the /debugfs/tracing/process_trace_README:
>
> process event tracer mini-HOWTO
>
> 1. Select process hierarchy to monitor. Other processes will be
> completely unaffected. Leave at 0 for system-wide trac
* Roland McGrath wrote:
> > kernel/utrace.c should probably be introduced as
> > kernel/trace/utrace.c not kernel/utrace.c. It also overlaps pending
> > work in the tracing tree and cooperation would be nice and desired.
>
> Of course I would like to cooperate with everyone. And of course
>
> And i think the ptrace-via-utrace engine is actually fully ready,
> just perhaps it was not submitted out of caution to keep the
> logistics simple.
That's not so. There is a clumsy prototype version. Much of the work to
do it properly is really just plain ptrace clean-up and not specificall
> kernel/utrace.c should probably be introduced as
> kernel/trace/utrace.c not kernel/utrace.c. It also overlaps pending
> work in the tracing tree and cooperation would be nice and desired.
Of course I would like to cooperate with everyone. And of course it does
not really matter much where a
> Yes, I believe that is Roland's intent. I believe it was separated
> from the current suite of patches for staging purposes, to merge the
> most solid code up first. The code is available from the utrace git
> tree in the utrace-ptrace branch.
More than just "staging". The utrace-ptrace code
> Well I dunno. You guys are closer to this than I am, but I'd have thought
> that systemtap is the main game here, and most/all of the above is just
> fluff.
That is certainly not true for me. It is true that I hear plenty from
systemtap developers, users, and boosters wanting utrace to be merg
* Ingo Molnar wrote:
> Total download size: 329 M
>
> That size of a _compressed_ debuginfo kernel package is obscene.
> We can fit 4 years of full Linux kernel Git history into that size
> - 60,000+ commits, full metadata and full 20 million lines of code
> flux included!
>
> Uncompressed
* Linus Torvalds wrote:
> On Sat, 21 Mar 2009, Frank Ch. Eigler wrote:
> >
> > > If testing utrace against its main application requires installation
> > > of a complete enterprise distro from a distro [...]
> >
> > This has *never* been a requirement.
>
> You guys are getting off a tangent.
* Diego Calleja wrote:
> On Sábado 21 Marzo 2009 16:45:01 Ingo Molnar escribió:
>
> > The main issue i see is that no kernel developer i work with on a
> > daily basis uses SystemTap - and i work with a lot of people. Yes, i
> > could perhaps name two or three people from lkml using it, but i
* Frank Ch. Eigler wrote:
> Hi -
>
> On Sat, Mar 21, 2009 at 04:45:01PM +0100, Ingo Molnar wrote:
> > [...]
> > To me personally there are two big direct usability issues with
> > SystemTap:
> >
> > 1) It relies on DEBUG_INFO for any reasonable level of utility.
> > Yes, it will limp alo
* Frank Ch. Eigler wrote:
> Hi -
>
> On Sun, Mar 22, 2009 at 01:37:59AM +0300, Alexey Dobriyan wrote:
> > [...]
> > struct task_struct::utrace became embedded struct. This is good and
> > should remove quite a few of utrace bugs. Better late than never.
>
> Yeah.
>
> > However, "rewrite-ptrac
Hi -
On Sun, Mar 22, 2009 at 01:37:59AM +0300, Alexey Dobriyan wrote:
> [...]
> struct task_struct::utrace became embedded struct. This is good and
> should remove quite a few of utrace bugs. Better late than never.
Yeah.
> However, "rewrite-ptrace-via-utrace" patch was omitted, so almost
> noon
On Sat, Mar 21, 2009 at 06:20:30PM -0400, Frank Ch. Eigler wrote:
> On Sat, Mar 21, 2009 at 03:02:59PM -0700, Linus Torvalds wrote:
> > [...]
> > > The thing is, utrace crashes in Fedora have dominated kerneloops.org
> > > for many months [...]
> >
> > .. and dammit, I agree 100%. If utrace reall
Hi -
On Sat, Mar 21, 2009 at 03:02:59PM -0700, Linus Torvalds wrote:
> [...]
> > The thing is, utrace crashes in Fedora have dominated kerneloops.org
> > for many months [...]
>
> .. and dammit, I agree 100%. If utrace really shows up in _any_ way on
> kerneloops.org, then I think THE ENTIRE DI
On Sat, 21 Mar 2009, Frank Ch. Eigler wrote:
>
> > If testing utrace against its main application requires installation
> > of a complete enterprise distro from a distro [...]
>
> This has *never* been a requirement.
You guys are getting off a tangent.
Let's go back to the post that started t
Hi -
On Sat, Mar 21, 2009 at 02:34:13PM -0700, Andrew Morton wrote:
> [...]
> It would not be good to merge a large kernel feature which kernel
> developers and testers cannot test, and regression test.
It does not. Other kernel self-sufficient utrace clients are on their
way, and of course one
Hi -
On Sat, Mar 21, 2009 at 04:45:01PM +0100, Ingo Molnar wrote:
> [...]
> To me personally there are two big direct usability issues with
> SystemTap:
>
> 1) It relies on DEBUG_INFO for any reasonable level of utility.
> Yes, it will limp along otherwise as well, but most of the
> act
On Sat, 21 Mar 2009 16:45:01 +0100 Ingo Molnar wrote:
>
> [...]
>
useful, thanks.
> Putting utrace upstream now will just make it more
> convenient to have SystemTap as a separate entity - without any of
> the benefits. Do we want to do that? Maybe, but we could do better i
> think.
It wou
On Sábado 21 Marzo 2009 16:45:01 Ingo Molnar escribió:
> The main issue i see is that no kernel developer i work with on a
> daily basis uses SystemTap - and i work with a lot of people. Yes, i
> could perhaps name two or three people from lkml using it, but its
> average penetration amongst ke
* Andrew Morton wrote:
> [...] Let's fix systemtap?
Yes, it needs to be fixed.
The main issue i see is that no kernel developer i work with on a
daily basis uses SystemTap - and i work with a lot of people. Yes, i
could perhaps name two or three people from lkml using it, but its
average p
Hi -
On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> [...]
> > There have been many mixed messages from LKML on the topic - sometimes
> > mentioning systemtap is forbidden, other times necessary. Sorry about
> > that.
>
> heh. We all love systemtap and want it to get better.
G
On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" wrote:
> Hi -
>
> On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> > [...]
> > > Utrace is very much tracing material - without the ftrace plugin the
> > > whole utrace machinery is just something that provides a _ton_ of
>
Hi -
On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> [...]
> > Utrace is very much tracing material - without the ftrace plugin the
> > whole utrace machinery is just something that provides a _ton_ of
> > hooks to something entirely external: SystemTap mainly.
>
> Roland's cha
On Sat, 21 Mar 2009 10:12:35 +0100 Ingo Molnar wrote:
>
> * Andrew Morton wrote:
>
> > On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar wrote:
> >
> > >
> > > * Roland McGrath wrote:
> > >
> > > > From: Frank Ch. Eigler
> > > >
> > > > This is v2 of the prototype utrace-ftrace interface.
* Andrew Morton wrote:
> On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar wrote:
>
> >
> > * Roland McGrath wrote:
> >
> > > From: Frank Ch. Eigler
> > >
> > > This is v2 of the prototype utrace-ftrace interface. This code is
> > > based on Roland McGrath's utrace API, which provides prog
On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar wrote:
>
> * Roland McGrath wrote:
>
> > From: Frank Ch. Eigler
> >
> > This is v2 of the prototype utrace-ftrace interface. This code is
> > based on Roland McGrath's utrace API, which provides programmatic
> > hooks to the in-tree tracehook
* Roland McGrath wrote:
> From: Frank Ch. Eigler
>
> This is v2 of the prototype utrace-ftrace interface. This code is
> based on Roland McGrath's utrace API, which provides programmatic
> hooks to the in-tree tracehook layer. This new patch interfaces
> many of those events to ftrace, as
From: Frank Ch. Eigler
This is v2 of the prototype utrace-ftrace interface. This code is
based on Roland McGrath's utrace API, which provides programmatic
hooks to the in-tree tracehook layer. This new patch interfaces many
of those events to ftrace, as configured by a small number of debugfs
c
44 matches
Mail list logo
