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: <cb8ab959-ca2e-034a-ad0c-2d6eeaa77f3c@iogearbox.net>
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!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ