Message-ID: <22d7bca2-cdfb-4e06-acb2-41363ba13333@gmail.com>
Date: Sat, 26 Apr 2025 11:39:05 +0900
From: Akira Yokosawa <akiyks@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: airlied@...il.com, corbet@....net, dri-devel@...ts.freedesktop.org,
 intel-gfx@...ts.freedesktop.org, jani.nikula@...ux.intel.com,
 joonas.lahtinen@...ux.intel.com, linux-doc@...r.kernel.org,
 linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
 maarten.lankhorst@...ux.intel.com, masahiroy@...nel.org, mripard@...nel.org,
 nathan@...nel.org, nicolas.schier@...ux.dev, rodrigo.vivi@...el.com,
 simona@...ll.ch, tursulin@...ulin.net, tzimmermann@...e.de,
 mchehab+huawei@...nel.org, Akira Yokosawa <akiyks@...il.com>
Subject: Re: [PATCH v4 0/4] Don't create Python bytecode when building the
 kernel

Hi Andy,

Responding to Mauro's cover-letter of v4 at:

    https://lore.kernel.org/cover.1745453655.git.mchehab+huawei@kernel.org/

, which did not CC'd to you.

On Thu, 24 Apr 2025 08:16:20 +0800, Mauro Carvalho Chehab wrote:
> As reported by Andy, the Kernel build system runs kernel-doc script for DRM,
> when W=1. Due to Python's normal behavior, its JIT compiler will create
> a bytecode and store it under scripts/lib/*/__pycache__.  As one may be using
> O= and even having the sources on a read-only mount point, disable its
> creation during build time.
> 
> This is done by adding PYTHONDONTWRITEBYTECODE=1 on every place
> where the script is called within Kbuild and when called via another script.
>  
> This only solves half of the issue though, as one may be manually running
> the script by hand, without asking Python to not store any bytecode.
> This should be OK, but afterwards, git status will list the __pycache__ as
> not committed. To prevent that, add *.pyc to .gitignore.
> 
> This series contain 4 patches:
> 
> - patch 1 adjusts a variable that pass extra data to scripts/kerneldoc.py;
> - patch 2moves scripts/kernel-doc location to the main makefile
>   and exports it, as scripts/Makefile.build will need it;
> - patch 3 disables __pycache__ generation and ensure that the entire Kbuild
>   will use KERNELDOC var for the location of kernel-doc;
> - patch 4 adds *.pyc at the list of object files to be ignored.

I see Jon has merged them all, but responding here anyway.

In https://lore.kernel.org/Z_zYXAJcTD-c3xTe@black.fi.intel.com/, you said:

> This started well, until it becomes a scripts/lib/kdoc.
> So, it makes the `make O=...` builds dirty *). Please make sure this doesn't leave
> "disgusting turd" )as said by Linus) in the clean tree.
>
>*) it creates that __pycache__ disaster. And no, .gitignore IS NOT a solution.w

Andy, I don't agree with your words "__pycache__ disaster" and 
".gitignore IS NOT a solution".

Running "find . -name ".gitignore" -exec grep -nH --null -F -e ".pyc" \{\} +"
under today's Linus master returns this:

-------------------------------------------------------------
./scripts/gdb/linux/.gitignore:2:*.pyc
./drivers/comedi/drivers/ni_routing/tools/.gitignore:3:*.pyc
./tools/perf/.gitignore:32:*.pyc
./tools/testing/selftests/tc-testing/.gitignore:3:*.pyc
./Documentation/.gitignore:3:*.pyc
-------------------------------------------------------------

, and they have been working perfectly.

Having seen your response at https://lore.kernel.org/aAoERIArkvj497ns@smile.fi.intel.com/ :

> I tried before, but I admit, that I have missed something. It was a mess
> in that case. Now I probably can't repeat as I don't remember what was
> the environment and settings I had that time. I'm really glad to see it
> is working this way!

, I'm guessing you had a traumatic experience caused by python's bytecode
caching in the past.  Do you still believe ".gitignore IS NOT a solution"?

>From my viewpoint, applying only 4/4 of this series is the right thing to do.

Bothering with might-become-incompatilbe-in-the-future python environment
variables in kernel Makefiles looks over-engineering to me.
Also, as Mauro says in 3/4, it is incomplete in that it does not cover
the cases where those scripts are invoked outside of kernel build.
And it will interfere with existing developers who want the benefit of
bytecode caching.

I'm not precluding the possibility of incoherent bytecode cache; for example
by using a shared kernel source tree among several developers, and only
one of them (owner) has a write permission of it.  In that case, said
owner might update the tree without running relevant python scripts.

I don't know if python can notice outdated cache and disregard it.

In such a situation, setting PYTHONPYCACHEPREFIX as an environment
variable should help, for sure, but only in such special cases.

Andy, what do you say if I ask reverts of 1/4, 2/4/, and 3/4?

Regards,
Akira

Powered by blists - more mailing lists