Date:   Thu, 18 Aug 2022 11:03:35 +0800
From:   Leo Yan <leo.yan@...aro.org>
To:     Chuck Zmudzinski <brchuckz@...scape.net>
Cc:     Ian Rogers <irogers@...gle.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alan Bartlett <ajb@...epo.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        linux-perf-users@...r.kernel.org, ElRepo <contact@...epo.org>,
        Akemi Yagi <toracat@...epo.org>, Jiri Olsa <jolsa@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Namhyung Kim <namhyung@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf scripts python: Let script to be python2 compliant

On Wed, Aug 17, 2022 at 09:12:24PM -0400, Chuck Zmudzinski wrote:

[...]

> > > > > > Someone reported a problem in a system they used, the author of the code
> > > > > > in question posted a patch allowing perf to be used in such old systems,
> > > > > > doesn't get in the way of newer systems, small patch, merged, life goes
> > > > > > on.
> > > >
> > > > Considering the proposed patch, can you be sure that replacing the
> > > > f-string format with the legacy format won't cause a regression for
> > > > some python3 user somewhere when this hits the real world? Even
> > > > if it does not cause a regression today, as new versions and features
> > > > are added to python3, can you be sure none of those new features
> > > > will depend on the upgrade from the legacy format to the f-string
> > > > format here to work properly? So many regressions happen because
> > > > the people who write patches cannot possibly foresee how their
> > > > patch is going to affect the millions of Linux users out there, but still
> > > > they are certain it will not cause a regression somewhere. So how
> > > > can the chances that this patch will cause a regression be minimized?
> > > >
> > > > It seems to me for this to be suitable for the Linux kernel, the
> > > > default should be to use the modern python3 format and only
> > > > enable python2 compatibility via a sysctl setting and/or kernel boot
> > > > option for those who are still using python2. There should be no
> > > > change to the behavior of the kernel for users who have upgraded
> > > > to python3. But I don't see any such consideration for python3
> > > > users in this patch.
> > >
> > > Sorry, I didn't see this is a script, LOL! So obviously a sysctl or boot option
> > > does not apply. But can't the script implement this simple logic:
> > >
> > > If python version = 3 use f-string format
> > > if python version = 2 use traditional string format
> >
> > Doing this in the script would be noisy, having two scripts less than
> > ideal. I'd suggest we wait two weeks, declare the official death of
> > RHEL7 without "rpm -i python3" and then revert the python3 to python2
> > patch. There are plenty of things to worry about and python2 shouldn't
> > be one of them (it died over 2 years ago).
> 
> I see this has already been committed. I agree it should not
> stay in the kernel tree for long. At some point in the future
> it will most likely cause problems if it is not reverted.

It is a bit confused me that here actually we are worrying about the
python distro issue, e.g. python2 is obsolete, so it's risky to keep
using python2 in the system, especially if python2 has potential
security issue.  So the system (e.g. RHEL7) needs to upgrade its python
distro from python2 to python3.

But this doesn't mean the python script cannot be compatible for both
python2 and python3.  I verified this patch, it should can work for
both python2 and python3 on my PC.

Another concern is there have some python scripts in perf, I think most
of them are python2 compatible, should we update all of them to be only
python3 compatible?

Thanks,
Leo

Powered by blists - more mailing lists