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]
Date:   Sat, 12 Aug 2023 10:35:09 +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,

> > Provide some suggestions that who deal with Netlink code could follow
> > (of course using the word "best-practices" may sound somewhat
> > exaggerate).
> 
> I truly appreciate the effort, but I'm worried this will only confuse
> developers. This document does not reflect the reality of writing new
> netlink families at all. It's more of a historic perspective.

While I understand your concerns, I have a slightly different perspective
on the statement that it "does not reflect the reality... at all."
The "About General Netlink Case" section does highlight some important
considerations for writing new netlink families, such as using helpers to
access nlattr and avoiding deprecated parsers.

However, I do acknowledge that the second best practice could be
confusing, as developers who use auto C code generation may not encounter
the issues mentioned.

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. 
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?

Thank you for your time and consideration. Have a great weekend. :D

Regards
Lin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ