Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753680Ab0AZVbu (ORCPT ); Tue, 26 Jan 2010 16:31:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752677Ab0AZVbt (ORCPT ); Tue, 26 Jan 2010 16:31:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56076 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752649Ab0AZVbs (ORCPT ); Tue, 26 Jan 2010 16:31:48 -0500 Date: Tue, 26 Jan 2010 22:30:10 +0100 From: Oleg Nesterov To: Linus Torvalds Cc: Andi Kleen , tromey@redhat.com, Stephen Rothwell , Kyle Moffett , Peter Zijlstra , Peter Zijlstra , Fr??d??ric Weisbecker , Steven Rostedt , LKML , Arnaldo Carvalho de Melo , "Frank Ch. Eigler" , linux-next@vger.kernel.org, "H. Peter Anvin" , utrace-devel@redhat.com, Thomas Gleixner Subject: Re: linux-next: add utrace tree Message-ID: <20100126213010.GA19146@redhat.com> References: <20100122200129.GG22003@redhat.com> <20100122221348.GA4263@redhat.com> <877hr4g49l.fsf@basil.nowhere.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1484 Lines: 37 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/