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]
Message-ID: <7cba74b5.10d19d.189fa27935c.Coremail.linma@zju.edu.cn>
Date:   Wed, 16 Aug 2023 01:04:04 +0800 (GMT+08:00)
From:   "Lin Ma" <linma@....edu.cn>
To:     "Jakub Kicinski" <kuba@...nel.org>
Cc:     corbet@....net, davem@...emloft.net, edumazet@...gle.com,
        pabeni@...hat.com, rdunlap@...radead.org, void@...ifault.com,
        jani.nikula@...el.com, horms@...nel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v3] docs: net: add netlink attrs best practices

Hello Jakub,

> 
> On Sat, 12 Aug 2023 10:35:09 +0800 (GMT+08:00) Lin Ma wrote:
> > Moving forward, I suggest we consider the following options:
> > 
> > 1. Update the document to address the confusion and make it more relevant
> >    to the current state of Netlink development. Maybe the newly added
> >    section seems not enough for that. I would greatly appreciate any
> >    specific guidance.
> 
> Unless we have docs for kernel side of modern genetlink any sort of
> indication that this doc is only a guide for looking at old code will
> fall on deaf ears.
> 
> So you'd need to write a sample family and docs for modern stuff.

Great, I guess I (finally) understand the situation here. It seems that
this document is just one piece of the puzzle when it comes to the modern
generic Netlink. Hence, I should write a sample family and docs for modern
stuff (mainly the kernel side) and then make this document one part of it.

> 
> > 2. If the document is deemed too outdated for being kernel documentation,
> >    maybe I should publish it somewhere else. Do you have any
> >    recommendations on where it could be better suited?
> 
> GitHub comes to mind for publishing ReST docs, in the meantime?

No worries. I'm just brainstorming ways to make these practices useful if they
didn't make it into the kernel document :D.
All in all, I'll follow up on our previous discussion and fill in the gaps as
soon as possible.

Regards
Lin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ