Message-ID: <CAP-5=fXj1-wqt+Bs-0ZypRsaZw2VP0qyKdeeRHpjUD5BwO9OBg@mail.gmail.com>
Date: Mon, 4 Nov 2024 13:06:35 -0800
From: Ian Rogers <irogers@...gle.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>, Peter Zijlstra <peterz@...radead.org>, 
	Ingo Molnar <mingo@...hat.com>, Mark Rutland <mark.rutland@....com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>, 
	James Clark <james.clark@...aro.org>, Howard Chu <howardchu95@...il.com>, 
	Athira Jajeev <atrajeev@...ux.vnet.ibm.com>, Michael Petlan <mpetlan@...hat.com>, 
	Veronika Molnarova <vmolnaro@...hat.com>, Dapeng Mi <dapeng1.mi@...ux.intel.com>, 
	Thomas Richter <tmricht@...ux.ibm.com>, Ilya Leoshkevich <iii@...ux.ibm.com>, 
	Colin Ian King <colin.i.king@...il.com>, Weilin Wang <weilin.wang@...el.com>, 
	Andi Kleen <ak@...ux.intel.com>, Josh Poimboeuf <jpoimboe@...hat.com>, linux-kernel@...r.kernel.org, 
	linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v5 06/21] perf script: Move find_scripts to browser/scripts.c

On Mon, Nov 4, 2024 at 1:00 PM Namhyung Kim <namhyung@...nel.org> wrote:
>
> On Mon, Nov 04, 2024 at 12:48:01PM -0800, Ian Rogers wrote:
> > On Mon, Nov 4, 2024 at 12:39 PM Arnaldo Carvalho de Melo
> > <acme@...nel.org> wrote:
> > >
> > > On Mon, Nov 04, 2024 at 12:34:47PM -0800, Ian Rogers wrote:
> > > > On Mon, Nov 4, 2024 at 11:47 AM Namhyung Kim <namhyung@...nel.org> wrote:
> > > > >
> > > > > On Thu, Oct 31, 2024 at 01:51:36PM -0700, Ian Rogers wrote:
> > > > > > On Thu, Oct 31, 2024 at 12:18 PM Arnaldo Carvalho de Melo
> > > > > > <acme@...nel.org> wrote:
> > > > > > >
> > > > > > > On Wed, Oct 30, 2024 at 06:42:37PM -0700, Ian Rogers wrote:
> > > > > > > > The only use of find_scripts is in browser/scripts.c but the
> > > > > > > > definition in builtin causes linking problems requiring a stub in
> > > > > > > > python.c. Move the function to allow the stub to be removed.
> > > > > > > >
> > > > > > > > Rewrite the directory iteration to use openat so that large character
> > > > > > > > arrays aren't needed. The arrays are warned about potential buffer
> > > > > > > > overflows by GCC now that all the code exists in a single C file.
> > > > > > >
> > > > > > > Introducing is_directory_at() should be done as a prep patch, as the
> > > > > > > rest of the patch below could end up being reverted after some other
> > > > > > > patch used it, making the process more difficult.
> > > > > > >
> > > > > > > I mentioned cases like this in the past, so doing it again just for the
> > > > > > > record.
> > > > > >
> > > > > > This is highlighted in the commit message:
> > > > > > ```
> > > > > > Rewrite the directory iteration to use openat so that large character
> > > > > > arrays aren't needed. The arrays are warned about potential buffer
> > > > > > overflows by GCC now that all the code exists in a single C file.
> > > > > > ```
> > > > > > so without the change the code wouldn't build. The new is_directory_at
> > > > > > function is effectively 2 statements fstatat and S_ISDIR on the
> > > > > > result, it is put next to is_directory for consistency but could have
> > > > > > been a static function in the only C file to use it.
> > > > > >
> > > > > > For the record, patches introducing 2 line long functions can be
> > > > > > excessively noisy, especially in a 21 patch series. There is always
> > > > > > the declared but not used build error to worry about - here things
> > > > > > couldn't just be simply moved due to triggering a different build
> > > > > > error. Given the simplicity of the function here I made a decision not
> > > > > > to split up the work - the commit message would likely be longer than
> > > > > > the function. The work never intended to introduce is_directory_at but
> > > > > > was forced into it through a desire not to disable compiler warnings.
> > > > >
> > > > > This patch does more than just moving the code which can be easy to miss
> > > > > something in the middle.  I think you can move the code as is without
> > > > > introducing build errors and then add new changes like using openat() on
> > > > > top (you may separate the change out of this series).  I think it's
> > > > > ok to have a small change if it clearly has different semantics.
> > > >
> > > > If you are trying to bisect to find something that broke a build,
> > > > having commits that knowingly break the build will cause the bisect to
> > > > fail. The bisect will falsely fail on the known to be broken commit.
> > >
> > > I'm not understanding, AFAIK nobody is advocating for breaking
> > > bisection, just to first instroduce a function, then use it to avoid:
> > >
> > > 1) Introduce function foo() and use it for feature bar()
> > > 2) Somebody else uses function foo()
> > > 3) We find a justification to revert 1) but can't, since it will break
> > >    2) so we need to add 4) that removes bar() from 1).
> >
> > Namhyung was asking that the c&p of code be 1 patch then "add new
> > changes like using openat() on top". That is:
> >
> > patch 1: add is_directory_at - introduce the 2 line helper function
> > patch 2: move the code
> > patch 3: update the code to use is_directory_at
> >
> > patch 2 is known broken as patch 3 is fixing it.
> >
> > Hopefully this is clear.
>
> Actually I don't care about the patch ordering.  My request is not
> to break build and just to separate different changes out. :)

So, patch 2 can't be separated from patch 3 - are we agreed? So we
squash patch 2 with patch 3. Patch 1 is trivial and fails to meet the
bar of a meaningful change, so we squash that. We end up with this
patch. If there's a later revert and a dependence of the 2 liner, just
don't revert that part of the change. We've never had such a revert so
it is hard to see why we need to generate so much churn because of it.

Thanks,
Ian

Powered by blists - more mailing lists