Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754799AbYGWJcU (ORCPT ); Wed, 23 Jul 2008 05:32:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752266AbYGWJcK (ORCPT ); Wed, 23 Jul 2008 05:32:10 -0400 Received: from il.qumranet.com ([212.179.150.194]:20623 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751942AbYGWJcJ (ORCPT ); Wed, 23 Jul 2008 05:32:09 -0400 Message-ID: <4886FA97.40104@qumranet.com> Date: Wed, 23 Jul 2008 12:32:07 +0300 From: Avi Kivity User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Peter Zijlstra CC: Jan Kiszka , Mathieu Desnoyers , akpm@linux-foundation.org, Ingo Molnar , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, "Feng(Eric) Liu" Subject: Re: [patch 4/4] KVM-trace port to tracepoints References: <20080717155724.897537670@polymtl.ca> <20080717160003.359557938@polymtl.ca> <487F7800.4010502@siemens.com> <20080717172853.GB29855@Krystal> <488604F8.1040008@siemens.com> <48862B01.7070907@qumranet.com> <1216799346.7257.125.camel@twins> <4886E6FD.4090200@qumranet.com> <1216803303.7257.138.camel@twins> In-Reply-To: <1216803303.7257.138.camel@twins> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1246 Lines: 34 Peter Zijlstra wrote: > There are currently no trace_mark() sites in the kernel that I'm aware > of (except for the scheduler :-/, and those should be converted to > tracepoints ASAP). > > Andrew raised the whole point about trace_mark() generating an > user-visible interface and thus it should be stable, and I agree with > that. > > What that means is that trace_mark() can only be used for really stable > points. > > This in turn means we might as well use trace points. > > Which allows for the conclusion that trace_mark() is not needed and > could be removed from the kernel. > > However - it might be handy for ad-hoc debugging purposes that never see > the light of day (linus' git tree in this case). So on those grounds one > could argue against removing trace_mark But trace_mark() is so wonderful. Can't we just declare the tracemarks as a non-stable interface? Perhaps add an unstable_trace_mark() to make it clear. -- error compiling committee.c: too many arguments to function -- 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/