linux-kernel - Re: [PATCH v3] Documentation: Document each netlink family

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87jznqewa7.fsf@meer.lwn.net>
Date: Tue, 30 Jan 2024 07:22:08 -0700
From: Jonathan Corbet <corbet@....net>
To: Jani Nikula <jani.nikula@...ux.intel.com>, Breno Leitao
 <leitao@...ian.org>, kuba@...nel.org, "David
 S. Miller" <davem@...emloft.net>
Cc: linux-doc@...r.kernel.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, pabeni@...hat.com, edumazet@...gle.com
Subject: Re: [PATCH v3] Documentation: Document each netlink family

Jani Nikula <jani.nikula@...ux.intel.com> writes:

> On Tue, 21 Nov 2023, Breno Leitao <leitao@...ian.org> wrote:
>> This is a simple script that parses the Netlink YAML spec files
>> (Documentation/netlink/specs/), and generates RST files to be rendered
>> in the Network -> Netlink Specification documentation page.
>
> First of all, my boilerplate complaint: All extra processing for Sphinx
> should really be done using Sphinx extensions instead of adding Makefile
> hacks. I don't think it's sustainable to keep adding this stuff. We
> chose Sphinx because it is extensible, and to avoid the Rube Goldberg
> machine that the previous documentation build system was.

So I feel like we've (me included) have kind of sent Breno around in
circles on this one.  This *was* implemented as an extension once:

  https://lore.kernel.org/netdev/20231103135622.250314-1-leitao@debian.org/

At that time it seemed too complex, and I thought that an external
script would lead to a simpler implementation overall.  Perhaps I was
wrong.

I worry that a proliferation of extensions adds its own sort of
complexity and hazards - look at the things Vegard has fixed recently,
for example.  Relatively few people can work in that environment, and
extensions can make our version-support troubles worse.  So I'm not
fully sold on the idea that everything should be an extension,
especially if it can be expressed as a simple dependency and build step
in the makefile.

Some of the uglier makefile stuff we have is a different story...

Anyway, I apologize for my role in making this particular addition
harder than it needed to be.  Perhaps, for the future, we should put
together and agree on a document (of all things) on how we think this
sort of functionality should be added.

Thanks,

jon