linux-kernel - Re: [PATCH 0/1] fix rustdoc build detection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72kGvfB2wqAv-d7F9racGoSX+TOmezA=ip-E4ouva-0U=Q@mail.gmail.com>
Date: Tue, 18 Nov 2025 23:02:35 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc: Carlos Bilbao <carlos.bilbao@...nel.org>, 
	Linux Doc Mailing List <linux-doc@...r.kernel.org>, Jonathan Corbet <corbet@....net>, 
	Mauro Carvalho Chehab <mchehab@...nel.org>, linux-kernel@...r.kernel.org, 
	Miguel Ojeda <ojeda@...nel.org>
Subject: Re: [PATCH 0/1] fix rustdoc build detection

On Mon, Nov 17, 2025 at 1:32 PM Mauro Carvalho Chehab
<mchehab+huawei@...nel.org> wrote:
>
> Heh, the same applies to the current usage of htmldocs - specially
> when SPHINXDIRS is used, e.g. one doing, for instance:
>
>         make SPHINXDOCS=driver-api/<subsystem>
>
> may not be interested on building rust docs, which, on such case,
> may be a lot slower than a partial build. Also, I don't think that
> rustdoc currently does something similar to SPHINXDOCS.

If you mean building the Rust docs introduces extra work for people
building the HTML docs when that happens automatically, then yeah,
definitely.

Perhaps it could be skipped depending on what folders are requested.

> E.g. you would create a parser_rust.py module there, which would
> generate ReST output from the rust code(*).

To clarify, the idea of the "external references map file" in that
issue isn't to stop using `rustdoc`, but rather to allow `rustdoc` to
have (at least) the references to C items (e.g. a link to the rendered
`printk` docs at least to the source code where it is defined). In
other words, it is about allowing developrers to just write something
like [`printk()`] and the system would figure out how to link to the
right docs automatically.

We don't plan to stop using `rustdoc` -- its output is specialized for
Rust which makes it quite nice.

`rustdoc` can export JSON and that should be possible to use easily
from a Sphinx plugin without having to parse Rust from scratch, to at
least get some degree of Sphinx support. That would be nice for the
other outputs support like PDF as you mention, yeah, as well as having
independent-to-the-config docs. We discussed it a few times, but it
has never been a high priority, especially since `rustdoc` does its
job quite well.

Cheers,
Miguel