netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	linux-kernel@vger.kernel.org,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	Kees Cook <kees@kernel.org>, Russell King <linux@armlinux.org.uk>,
	linux-hardening@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v3 00/33] Implement kernel-doc in Python
Date: Tue, 15 Apr 2025 18:06:31 +0800	[thread overview]
Message-ID: <20250415180631.180e9a9f@sal.lan> (raw)
In-Reply-To: <Z_4sxCFvpqs7qmcN@smile.fi.intel.com>

Em Tue, 15 Apr 2025 12:54:12 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> escreveu:

> On Tue, Apr 15, 2025 at 12:51:38PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 15, 2025 at 04:40:34PM +0800, Mauro Carvalho Chehab wrote:  
> > > Em Tue, 15 Apr 2025 11:19:26 +0300
> > > Andy Shevchenko <andriy.shevchenko@intel.com> escreveu:  
> > > > On Tue, Apr 15, 2025 at 11:17:12AM +0300, Andy Shevchenko wrote:  
> > > > > On Tue, Apr 15, 2025 at 10:49:29AM +0300, Jani Nikula wrote:    
> > > > > > On Tue, 15 Apr 2025, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:    
> > > > > > > On Tue, Apr 15, 2025 at 10:01:04AM +0300, Andy Shevchenko wrote:    
> > > > > > >> On Mon, Apr 14, 2025 at 09:17:51AM -0600, Jonathan Corbet wrote:    
> > > > > > >> > Andy Shevchenko <andriy.shevchenko@intel.com> writes:    
> > > > > > >> > > On Wed, Apr 09, 2025 at 12:30:00PM -0600, Jonathan Corbet wrote:    
> > > > > > >> > >> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> > > > > > >> > >>     
> > > > > > >> > >> > This changeset contains the kernel-doc.py script to replace the verable
> > > > > > >> > >> > kernel-doc originally written in Perl. It replaces the first version and the
> > > > > > >> > >> > second series I sent on the top of it.    
> > > > > > >> > >> 
> > > > > > >> > >> OK, I've applied it, looked at the (minimal) changes in output, and
> > > > > > >> > >> concluded that it's good - all this stuff is now in docs-next.  Many
> > > > > > >> > >> thanks for doing this!
> > > > > > >> > >> 
> > > > > > >> > >> I'm going to hold off on other documentation patches for a day or two
> > > > > > >> > >> just in case anything turns up.  But it looks awfully good.    
> > > > > > >> > >
> > > > > > >> > > 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.    
> > > > > > >> > 
> > > > > > >> > If nothing else, "make cleandocs" should clean it up, certainly.
> > > > > > >> > 
> > > > > > >> > We can also tell CPython to not create that directory at all.  I'll run
> > > > > > >> > some tests to see what the effect is on the documentation build times;
> > > > > > >> > I'm guessing it will not be huge...    
> > > > > > >> 
> > > > > > >> I do not build documentation at all, it's just a regular code build that leaves
> > > > > > >> tree dirty.
> > > > > > >> 
> > > > > > >> $ python3 --version
> > > > > > >> Python 3.13.2
> > > > > > >> 
> > > > > > >> It's standard Debian testing distribution, no customisation in the code.
> > > > > > >> 
> > > > > > >> To reproduce.
> > > > > > >> 1) I have just done a new build to reduce the churn, so, running make again does nothing;
> > > > > > >> 2) The following snippet in shell shows the issue
> > > > > > >> 
> > > > > > >> $ git clean -xdf
> > > > > > >> $ git status --ignored
> > > > > > >> On branch ...
> > > > > > >> nothing to commit, working tree clean
> > > > > > >> 
> > > > > > >> $ make LLVM=-19 O=.../out W=1 C=1 CF=-D__CHECK_ENDIAN__ -j64
> > > > > > >> make[1]: Entering directory '...'
> > > > > > >>   GEN     Makefile
> > > > > > >>   DESCEND objtool
> > > > > > >>   CALL    .../scripts/checksyscalls.sh
> > > > > > >>   INSTALL libsubcmd_headers
> > > > > > >> .pylintrc: warning: ignored by one of the .gitignore files
> > > > > > >> Kernel: arch/x86/boot/bzImage is ready  (#23)
> > > > > > >> make[1]: Leaving directory '...'
> > > > > > >> 
> > > > > > >> $ touch drivers/gpio/gpiolib-acpi.c
> > > > > > >> 
> > > > > > >> $ make LLVM=-19 O=.../out W=1 C=1 CF=-D__CHECK_ENDIAN__ -j64
> > > > > > >> make[1]: Entering directory '...'
> > > > > > >>   GEN     Makefile
> > > > > > >>   DESCEND objtool
> > > > > > >>   CALL    .../scripts/checksyscalls.sh
> > > > > > >>   INSTALL libsubcmd_headers
> > > > > > >> ...
> > > > > > >>   OBJCOPY arch/x86/boot/setup.bin
> > > > > > >>   BUILD   arch/x86/boot/bzImage
> > > > > > >> Kernel: arch/x86/boot/bzImage is ready  (#24)
> > > > > > >> make[1]: Leaving directory '...'
> > > > > > >> 
> > > > > > >> $ git status --ignored
> > > > > > >> On branch ...
> > > > > > >> Untracked files:
> > > > > > >>   (use "git add <file>..." to include in what will be committed)
> > > > > > >> 	scripts/lib/kdoc/__pycache__/
> > > > > > >> 
> > > > > > >> nothing added to commit but untracked files present (use "git add" to track)    
> > > > > > >
> > > > > > > FWIW, I repeated this with removing the O=.../out folder completely, so it's
> > > > > > > fully clean build. Still the same issue.
> > > > > > >
> > > > > > > And it appears at the very beginning of the build. You don't need to wait to
> > > > > > > have the kernel to be built actually.    
> > > > > > 
> > > > > > kernel-doc gets run on source files for W=1 builds. See Makefile.build.    
> > > > > 
> > > > > Thanks for the clarification, so we know that it runs and we know that it has
> > > > > an issue.    
> > > > 
> > > > Ideal solution what would I expect is that the cache folder should respect
> > > > the given O=... argument, or disabled at all (but I don't think the latter
> > > > is what we want as it may slow down the build).  
> > > 
> > > From:
> > > 	https://github.com/python/cpython/commit/b193fa996a746111252156f11fb14c12fd6267e6
> > > and:
> > > 	https://peps.python.org/pep-3147/
> > > 
> > > It sounds that Python 3.8 and above have a way to specify the cache
> > > location, via PYTHONPYCACHEPREFIX env var, and via "-X pycache_prefix=path".
> > > 
> > > As the current minimal Python version is 3.9, we can safely use it.
> > > 
> > > So, maybe this would work:
> > > 
> > > 	make O="../out" PYTHONPYCACHEPREFIX="../out"
> > > 
> > > or a variant of it:
> > > 
> > > 	PYTHONPYCACHEPREFIX="../out" make O="../out" 
> > > 
> > > If this works, we can adjust the building system to fill PYTHONPYCACHEPREFIX
> > > env var when O= is used.  
> > 
> > It works,

Good!

> > the problem is that it should be automatically assigned to the
> > respective folder, so when compiling kdoc, it should be actually
> > 
> > $O/scripts/lib/kdoc/__pycache__
> > 
> > and so on for _each_ of the python code.  

Yeah, agreed. We need to think on a more generic solution though,
as we also may have scripts/lib/abi/__pycache__ if one runs
get_abi.pl, and, in the future, we may have more. Not sure how
hard/easy would be to do that, though.

> So, the bottom line, can we just disable it for a quick fix and when a proper
> solution comes, it will redo that?

Agreed, this sounds to be the best approach.

I'll try to craft a patch along the week to add
PYTHONDONTWRITEBYTECODE=1 to the places where kernel-doc
is called.

Regards,
Mauro


  reply	other threads:[~2025-04-15 10:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 10:09 [PATCH v3 00/33] Implement kernel-doc in Python Mauro Carvalho Chehab
2025-04-08 10:09 ` [PATCH v3 33/33] scripts: kernel-doc: fix parsing function-like typedefs (again) Mauro Carvalho Chehab
2025-04-09  5:29 ` [PATCH v3 00/33] Implement kernel-doc in Python Mauro Carvalho Chehab
2025-04-09 10:16 ` Jani Nikula
2025-04-09 11:44   ` Mauro Carvalho Chehab
2025-04-09 18:30 ` Jonathan Corbet
2025-04-14  9:41   ` Andy Shevchenko
2025-04-14 15:17     ` Jonathan Corbet
2025-04-14 15:54       ` Jonathan Corbet
2025-04-15  7:01       ` Andy Shevchenko
2025-04-15  7:03         ` Andy Shevchenko
2025-04-15  7:49           ` Jani Nikula
2025-04-15  8:17             ` Andy Shevchenko
2025-04-15  8:19               ` Andy Shevchenko
2025-04-15  8:40                 ` Mauro Carvalho Chehab
2025-04-15  8:51                   ` Mauro Carvalho Chehab
2025-04-15  9:53                     ` Andy Shevchenko
2025-04-15  9:51                   ` Andy Shevchenko
2025-04-15  9:54                     ` Andy Shevchenko
2025-04-15 10:06                       ` Mauro Carvalho Chehab [this message]
2025-04-15 11:13                         ` Andy Shevchenko
2025-04-15 13:34                         ` Jonathan Corbet
2025-04-16  6:44                           ` Mauro Carvalho Chehab
2025-04-15  8:30           ` Mauro Carvalho Chehab

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=20250415180631.180e9a9f@sal.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=corbet@lwn.net \
    --cc=gustavoars@kernel.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=kees@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    /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).