From: Jonathan Corbet <corbet@lwn.net>
To: Ignacio Encinas Rubio <ignacio@iencinas.com>,
Akira Yokosawa <akiyks@gmail.com>
Cc: dvyukov@google.com, elver@google.com, kasan-dev@googlegroups.com,
linux-doc@vger.kernel.org, linux-kernel-mentees@lists.linux.dev,
linux-kernel@vger.kernel.org, skhan@linuxfoundation.org,
workflows@vger.kernel.org
Subject: Re: [PATCH] Documentation: kcsan: fix "Plain Accesses and Data Races" URL in kcsan.rst
Date: Mon, 17 Mar 2025 17:03:28 -0600 [thread overview]
Message-ID: <87zfhjcla7.fsf@trenco.lwn.net> (raw)
In-Reply-To: <9c6298a2-4efa-4f77-81c0-b2132f48c1b0@iencinas.com>
Ignacio Encinas Rubio <ignacio@iencinas.com> writes:
> On 15/3/25 3:41, Akira Yokosawa wrote:
>> This might be something Jon would like to keep secret, but ...
>>
>> See the message and the thread it belongs at:
>>
>> https://lore.kernel.org/lkml/Pine.LNX.4.44L0.1907310947340.1497-100000@iolanthe.rowland.org/
>>
>> It happened in 2019 responding to Mauro's attempt to conversion of
>> LKMM docs.
>>
>> I haven't see any change in sentiment among LKMM maintainers since.
>
> Thanks for the information!
FWIW, I don't think it has really been discussed since.
>> Your way forward would be to keep those .txt files *pure plain text"
>> and to convert them on-the-fly into reST. Of course only if such an
>> effort sounds worthwhile to you.
>
> With this you mean producing a .rst from the original .txt file using an
> script before building the documentation, right? I'm not sure how hard
> this is, but I can look into it.
>
>> Another approach might be to include those docs literally.
>> Similar approach has applied to
>>
>> Documentation/
>> atomic_t.txt
>> atomic_bitops.txt
>> memory-barriers.txt
>
> Right, I got to [1].
>
> It looks like there are several options here:
>
> A) Include the text files like in [1]
> B) Explore the "on-the-fly" translation
> C) Do A) and then B)
>
> Does any of the above sound good, Jon?
Using the wrapper technique will surely work and should be an
improvement over what we have now. I don't hold out much hope for "on
the fly" mangling of the text - it sounds brittle and never quite good
enough, but I'm willing to be proved wrong on that front.
The original discussion from all those years ago centered around worries
about inserting lots of markup into the plain-text file. But I'm not
convinced that anything requires all that markup; indeed, the proposed
conversion at the time didn't do that. The question was quickly dropped
because we had so much to do back then...
I think there might be value in trying another minimal-markup
conversion; it would be *nicer* to use more fonts in the HTML version,
but not doing so seems better than not having an HTML version at all.
But, obviously, there are no guarantees that it will clear the bar.
Thanks,
jon
prev parent reply other threads:[~2025-03-17 23:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 21:11 Ignacio Encinas
2025-03-12 22:36 ` Jonathan Corbet
2025-03-14 16:30 ` Ignacio Encinas Rubio
2025-03-15 2:41 ` Akira Yokosawa
2025-03-15 12:21 ` Ignacio Encinas Rubio
2025-03-17 23:03 ` Jonathan Corbet [this message]
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=87zfhjcla7.fsf@trenco.lwn.net \
--to=corbet@lwn.net \
--cc=akiyks@gmail.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=ignacio@iencinas.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=workflows@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