From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752420AbYJTIuc (ORCPT ); Mon, 20 Oct 2008 04:50:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751287AbYJTIuY (ORCPT ); Mon, 20 Oct 2008 04:50:24 -0400 Received: from cn.fujitsu.com ([222.73.24.84]:57561 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751017AbYJTIuW (ORCPT ); Mon, 20 Oct 2008 04:50:22 -0400 Message-ID: <48FC45CD.1070101@cn.fujitsu.com> Date: Mon, 20 Oct 2008 16:48:13 +0800 From: Lai Jiangshan User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ingo Molnar CC: Mathieu Desnoyers , Linux Kernel Mailing List Subject: Re: [PATCH tip/tracing/markers] markers: simplify marker_set_format() References: <48F59425.40601@cn.fujitsu.com> <20081015134416.GA29281@Krystal> In-Reply-To: <20081015134416.GA29281@Krystal> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mathieu Desnoyers wrote: > * Lai Jiangshan (laijs@cn.fujitsu.com) wrote: >> current marker_set_format() is complex this patch simplify it, >> and decrease the overhead of marker_update_probes(). >> > > Yep, I think I did put the format string after the name \0, which was > rather tricky. I agree that such change makes the code more readable at > the expense of doing 2 allocations per marker rather than one, but > readability might be a good thing here. > > Thanks ! > > Acked-by: Mathieu Desnoyers > Hi, Ingo Do you have any objections against these patches? [PATCH tip/tracing/markers] markers: simplify marker_set_format() [PATCH tip/tracing/markers] markers: remove exported symbol marker_probe_cb_noarg() [PATCH tip/tracing/markers] markers: let marker_table be close to its comments My new patch are being made on the top of these patches. new patch: [PATCH tip/tracing/markers] markers: new callbacks manager new patch remove a lot code and speed up critical region and not change any APIs. new patch change too much code, so I have to wait until all known patches(which can be applied) have been applied. Thanks, Lai