Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210325184615.08526aed@coco.lan> <2cf44cf1fa42588632735d4fbc8e84304bdc235f.1616696051.git.mchehab+huawei@kernel.org>
 <87tuozyslu.fsf@meer.lwn.net> <20210325191435.GZ1719932@casper.infradead.org>
 <87a6qrx7wf.fsf@meer.lwn.net> <20210325221437.GA1719932@casper.infradead.org>
 <CANiq72=kRzBQsjgUeuVNXRmRVN8zXzMvMn+yTWt=YhR+r2wNEg@mail.gmail.com> <87wntooq71.fsf@intel.com>
In-Reply-To: <87wntooq71.fsf@intel.com>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Wed, 31 Mar 2021 00:46:18 +0200
Message-ID: <CANiq72kd+=LrWZEAN=eu9O49Vi+4bMBCjCN=uH6bs130kF9U9A@mail.gmail.com>
Subject: Re: [PATCH] kernel-doc: better handle '::' sequences
To:     Jani Nikula <jani.nikula@linux.intel.com>
Cc:     Matthew Wilcox <willy@infradead.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        Linux Doc Mailing List <linux-doc@vger.kernel.org>,
        Rob Herring <robh@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Mar 30, 2021 at 1:07 PM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> FWIW, and this should be obvious, I think going with what's natural for
> documenting Rust source code is the right choice. Markdown as parsed by
> rustdoc. People will expect Rust documentation comments to just work,
> without some kernel specific gotchas. Don't try to reinvent the wheel
> here, it's a dead end.

Agreed!

> The interesting question is, I think, figuring out if rustdoc output
> could be incorporated into Sphinx documentation, and how. It would be
> pretty disappointing if we ended up with two documentation silos based
> on the module implementation language.

I want to have the Rust docs linked from Sphinx and uploaded as usual
to kernel.org etc.

However, please note that the implementation language implies a lot of
things, not just the "implementation language", if that makes sense.

For instance, if you write your module in Rust, the idea is that you
use the Rust infrastructure and exposed abstractions -- not that you
call C kernel functions on your own.

> At the moment it seems to me rustdoc can only output HTML, and that
> seems pretty deeply ingrained in the tool. AFAICT, there isn't an
> intermediate phase where it would be trivial to output the documentation
> in Markdown (though I don't really know Rust and I only had a cursory
> look at librustdoc). And even if it were possible, with Markdown you'd
> have the issues with conflicting Markdown flavours, what's supported by
> rustdoc vs. commonmark.py used by Sphinx.

Please note that `rustdoc` generates HTML that is intended for Rust
code, i.e. generating an intermediate format to then generate HTML
from Sphinx would make the Rust docs worse, unless the mapping is
perfect (but, at that point, why not just keep the standard Rust
docs?).

> Perhaps the bare minimum is running rustdoc first, and generating the
> results into Sphinx static pages [1], to make them part of the
> whole. Even if the HTML style might be different. Perhaps it would be

I don't think it is the "bare minimum", I think this is the optimal
solution! :-)

It is also not just about the style. The Rust docs are organized for
Rust code, the search functionality is meant for it, etc.

> possible to come up with a Sphinx extensions to make it convenient to
> reference content in the rustdoc generated HTML from reStructuredText.

For C -> Rust links, the plan I suggested to Jonathan was to have
Sphinx generate a text file with (reference, URL) pairs that then
`rustdoc` can use as links (e.g. to link to, say, the docs for
`printk`).

I also discussed it with the `rustdoc` maintainers, and they thought
it would be an interesting proposal, so I agreed to make an RFC for it
(note that it can be useful not just for Rust docs that need to refer
to C code, but also for any other kind of external content, e.g.
imagine a math library referencing a set of papers, books, etc.
without having to re-write the URL everywhere).

Cheers,
Miguel