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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ