linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Akira Yokosawa <akiyks@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@intel.com>,
	airlied@gmail.com, corbet@lwn.net,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
	linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org,
	linux-kernel@vger.kernel.org, maarten.lankhorst@linux.intel.com,
	masahiroy@kernel.org, mripard@kernel.org, nathan@kernel.org,
	nicolas.schier@linux.dev, rodrigo.vivi@intel.com,
	simona@ffwll.ch, tursulin@ursulin.net, tzimmermann@suse.de
Subject: Re: [PATCH v4 0/4] Don't create Python bytecode when building the kernel
Date: Sat, 26 Apr 2025 20:57:08 +0800	[thread overview]
Message-ID: <20250426205708.4f90a83d@sal.lan> (raw)
In-Reply-To: <22d7bca2-cdfb-4e06-acb2-41363ba13333@gmail.com>

Hi Akira,

Em Sat, 26 Apr 2025 11:39:05 +0900
Akira Yokosawa <akiyks@gmail.com> escreveu:

> 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?

Patches 1 and 2 are, IMO, needed anyway, as they fix a problem:
KERNELDOC environment is not used consistently.

Now, patch 3 is the one that may require more thinking.

I agree with Andy that, when O=<dir> is used, nothing shall be
written to source dir.

There are a couple of reasons for that:

1. source dir may be read only;
2. one may want to do cross compilation and use multiple output
   directories, one for each version;
3. the source dir could be mapped via NFS to multiple machines
   with different architectures.

For (3), it could mean that multiple machines may have different
Python versions, so, sharing the Python bytecode from source dir doesn't
sound a good idea. Also, I'm not sure if the pyc from different archs
would be identical.

With that, there are two options:

a. disable cache;
b. set PYTHONCACHEPREFIX.

We're currently doing (a). I guess everybody agrees that this is
is not ideal.

So, ideally, we should move to (b). For Spinx, the easiest solution
is just to place it under Documentation/output, but this is not
generic enough: ideally, we should revert patch 3 and set
PYTHONCACHEPREFIX when O is used. Eventually, we can apply my
patch for Documentation/output, while we craft such logic.

Regards,
Mauro


  reply	other threads:[~2025-04-26 12:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-24  0:16 [PATCH v4 0/4] Don't create Python bytecode when building the kernel Mauro Carvalho Chehab
2025-04-24  0:16 ` [PATCH v4 1/4] docs: Makefile: get rid of KERNELDOC_CONF env variable Mauro Carvalho Chehab
2025-04-24  0:16 ` [PATCH v4 2/4] Makefile: move KERNELDOC macro to the main Makefile Mauro Carvalho Chehab
2025-04-24  0:16 ` [PATCH v4 3/4] scripts/kernel-doc.py: don't create *.pyc files Mauro Carvalho Chehab
2025-04-25 18:46   ` Nicolas Schier
2025-04-30 15:41     ` Mauro Carvalho Chehab
2025-04-24  0:16 ` [PATCH v4 4/4] .gitignore: ignore Python compiled bytecode Mauro Carvalho Chehab
2025-04-24 13:52   ` Miguel Ojeda
2025-04-24 16:19 ` [PATCH v4 0/4] Don't create Python bytecode when building the kernel Jonathan Corbet
2025-04-26  2:39 ` Akira Yokosawa
2025-04-26 12:57   ` Mauro Carvalho Chehab [this message]
2025-04-28  7:35     ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250426205708.4f90a83d@sal.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=airlied@gmail.com \
    --cc=akiyks@gmail.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=masahiroy@kernel.org \
    --cc=mripard@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nicolas.schier@linux.dev \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=tursulin@ursulin.net \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).