Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755101Ab0AWLs5 (ORCPT ); Sat, 23 Jan 2010 06:48:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754786Ab0AWLs4 (ORCPT ); Sat, 23 Jan 2010 06:48:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17707 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753850Ab0AWLsz (ORCPT ); Sat, 23 Jan 2010 06:48:55 -0500 Date: Sat, 23 Jan 2010 06:47:29 -0500 From: "Frank Ch. Eigler" To: Ingo Molnar Cc: Kyle Moffett , Linus Torvalds , Oleg Nesterov , Andrew Morton , Stephen Rothwell , Peter Zijlstra , Peter Zijlstra , Fr??d??ric Weisbecker , LKML , Steven Rostedt , Arnaldo Carvalho de Melo , linux-next@vger.kernel.org, "H. Peter Anvin" , utrace-devel@redhat.com, Thomas Gleixner Subject: Re: linux-next: add utrace tree Message-ID: <20100123114729.GA7828@redhat.com> References: <20100121170541.7425ff10.akpm@linux-foundation.org> <20100122182827.GA13185@redhat.com> <20100122200129.GG22003@redhat.com> <20100122221348.GA4263@redhat.com> <20100123112333.GA15455@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100123112333.GA15455@elte.hu> User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1387 Lines: 33 Hi - mingo wrote: > [...] > > Now how do we get from here to a moderately portable API for interrogating, > > controlling, and intercepting process state? Essentially it would need to > > support all of the things that a powerful debugger would want to do, > > including modifying registers and memory, substituting syscall return > > values, etc. I believe that "utrace" is the kernel side of that API. > > The problem is, utrace does not do that really. In fact, it is exactly designed for that. > What utrace does is that it provides an opaque set of APIs for > unspecified and out of tree _kernel_ modules (such as systemtap). It > doesnt support any 'application' per se. It basically removes the > kernel's freedom at shaping its own interaction with debug > application. This claim is hard to take any more seriously than emoting that the blockio layer is "opaque" because device drivers "remove freedom" for the kernel to "shape its interaction" with hardware. If you have any *real evidence* about how any present user of utrace misuses that capability, or interferes with the "kernel's freedom", show us please. - FChE -- 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/