[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100126213010.GA19146@redhat.com>
Date: Tue, 26 Jan 2010 22:30:10 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andi Kleen <andi@...stfloor.org>, tromey@...hat.com,
Stephen Rothwell <sfr@...b.auug.org.au>,
Kyle Moffett <kyle@...fetthome.net>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Peter Zijlstra <peterz@...radead.org>,
Fr??d??ric Weisbecker <fweisbec@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
"Frank Ch. Eigler" <fche@...hat.com>, linux-next@...r.kernel.org,
"H. Peter Anvin" <hpa@...or.com>, utrace-devel@...hat.com,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree
On 01/26, Linus Torvalds wrote:
>
> The problem is that anything that is based on reparenting and signals is
> fundamentally a "one parent only" kind of interface. See?
Indeed. signals + do_wait() is the horrible model.
> So the reason I think using an fd is a good idea is _not_ because gdb
> already uses an fd internally, but because it gives you a "connection"
> between the debugger and debuggee that is not fundamentally limited to a
> single controller.
>
> (It doesn't have to be a file descriptor, of course, but could be any kind
> of other model that allows multiple connections.
Yes.
But then we need something which represents this connection in kernel:
utrace_engine. Then we need something which allows multiple tracers to
cooperate. Just for example, one tracer wants to resume the tracee,
another tracer wants the tracee to be stopped. Utrace does this. And,
since we should preserve the current ptrace, the tracers should cooperate
with ptrace too.
IOW, this quickly leads to the new abstraction layer, I think. And of
course it is possible to implement this new model on top of utrace.
Yes, utrace itself comes with utrace_engine_ops vector to implement
"whatever you like", perhaps you dislike this part.
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