netdev - Re: [PATCH bpf-next v2] bpf: relax constraints on formatting for eBPF helper documentation

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:   Wed, 2 May 2018 17:48:26 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Quentin Monnet <quentin.monnet@...ronome.com>, ast@...nel.org
Cc:     dsahern@...il.com, yhs@...com, ecree@...arflare.com,
        netdev@...r.kernel.org, oss-drivers@...ronome.com
Subject: Re: [PATCH bpf-next v2] bpf: relax constraints on formatting for eBPF
 helper documentation

On 05/02/2018 03:20 PM, Quentin Monnet wrote:
> The Python script used to parse and extract eBPF helpers documentation
> from include/uapi/linux/bpf.h expects a very specific formatting for the
> descriptions (single dot represents a space, '>' stands for a tab):
> 
>     /*
>      ...
>      *.int bpf_helper(list of arguments)
>      *.>    Description
>      *.>    >       Start of description
>      *.>    >       Another line of description
>      *.>    >       And yet another line of description
>      *.>    Return
>      *.>    >       0 on success, or a negative error in case of failure
>      ...
>      */
> 
> This is too strict, and painful for developers who wants to add
> documentation for new helpers. Worse, it is extremely difficult to check
> that the formatting is correct during reviews. Change the format
> expected by the script and make it more flexible. The script now works
> whether or not the initial space (right after the star) is present, and
> accepts both tabs and white spaces (or a combination of both) for
> indenting description sections and contents.
> 
> Concretely, something like the following would now be supported:
> 
>     /*
>      ...
>      *int bpf_helper(list of arguments)
>      *......Description
>      *.>    >       Start of description...
>      *>     >       Another line of description
>      *..............And yet another line of description
>      *>     Return
>      *.>    ........0 on success, or a negative error in case of failure
>      ...
>      */
> 
> While at it, remove unnecessary carets from each regex used with match()
> in the script. They are redundant, as match() tries to match from the
> beginning of the string by default.
> 
> v2: Remove unnecessary caret when a regex is used with match().
> 
> Signed-off-by: Quentin Monnet <quentin.monnet@...ronome.com>

Applied to bpf-next, thanks Quentin!