linux-kernel - Re: [PATCH RFC] Rework the top-level process page

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] [day] [month] [year] [list]

Date: Thu, 21 Dec 2023 07:34:53 +0100
From: Vegard Nossum <vegard.nossum@...cle.com>
To: Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] Rework the top-level process page


On 09/12/2023 01:15, Jonathan Corbet wrote:
> The process book is arguably the most important documentation we have; the
> top three trafficked pages on docs.kernel.org are found here.  Make a
> beginning effort to impose a more useful organization on this page to ease
> developers into the community.
> ---
> This is a version of the reworked page I showed briefly during the
> kernel-summit documentation session.  Perhaps more useful than the patch
> itself is the rendered version of the page, which can be seen at:
> 
>    https://static.lwn.net/kerneldoc/process/index.html
> 
> There is a lot to do to turn this book into a coherent set of
> documentation, but this seems like a plausible step in that direction.

I think the reworked page is clearly an improvement.

The following is not really a comment on your patch specifically, but on
the page in general:

"""
Tools and technical guides for kernel developers

This is a collection of material that kernel developers should be
familiar with.

     Minimal requirements to compile the Kernel
     Programming Language
     Linux kernel coding style
     Kernel Maintainer PGP guide
     Email clients info for Linux
     Applying Patches To The Linux Kernel
     Backporting and conflict resolution
     Adding a New System Call
     Why the "volatile" type class should not be used
     (How to avoid) Botching up ioctls
"""

I think the last three links probably belong somewhere else -- for me,
those are not process-related but actual kernel-code-technical
information. The same goes for "Unaligned Memory Accesses" at the bottom
of the page.

How about putting these somewhere under kernel-hacking/ (AKA "Kernel
Hacking Guides")?


Vegard