From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751970AbdHGUQb (ORCPT ); Mon, 7 Aug 2017 16:16:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27360 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751564AbdHGUQa (ORCPT ); Mon, 7 Aug 2017 16:16:30 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1CFE383F3F Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=acme@redhat.com Date: Mon, 7 Aug 2017 17:16:27 -0300 From: Arnaldo Carvalho de Melo To: Milian Wolff Cc: Arnaldo Carvalho de Melo , Jin Yao , Linux-kernel@vger.kernel.org, Namhyung Kim , linux-perf-users@vger.kernel.org, David Ahern , Peter Zijlstra Subject: Re: [PATCH v2 01/14] perf report: remove code to handle inline frames from browsers Message-ID: <20170807201627.GH3647@redhat.com> References: <20170806212446.24925-1-milian.wolff@kdab.com> <20170806212446.24925-2-milian.wolff@kdab.com> <20170807150710.GQ12201@kernel.org> <1919153.sx2P4c3EvB@agathebauer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1919153.sx2P4c3EvB@agathebauer> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.20 (2009-12-10) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 07 Aug 2017 20:16:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Mon, Aug 07, 2017 at 09:22:08PM +0200, Milian Wolff escreveu: > On Montag, 7. August 2017 17:07:10 CEST Arnaldo Carvalho de Melo wrote: > > Em Sun, Aug 06, 2017 at 11:24:33PM +0200, Milian Wolff escreveu: > > > The follow-up commits will make inline frames first-class citizens > > > in the callchain, thereby obsoleting all of this special code. > > So you are removing the feature to then reintroduce it, is that it? That > > is not usual :-\ > > Normally we go on replacing bit by bit or have some ifdef, etc, to then > > phase out the old code. > > Perhaps in this case your approach is the best one, still have to look > > at all of it, and it would help if the people behind the original code > > could review this, Yao Jin, can you take a look at this patch series, > > please? > Yes, I also did that in v1 of this patch series. Note that I can easily squash > this, if needed. But I personally think for reviewing purposes, having it as > separate patches is far better. Well, if it is a full blown alternative implementation, like it seems to be (haven't started reviewing yet), probably. - Arnaldo