From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Borkmann Subject: Re: [PATCH bpf-next v2] bpf: relax constraints on formatting for eBPF helper documentation Date: Wed, 2 May 2018 17:48:26 +0200 Message-ID: References: <20180502132024.14550-1-quentin.monnet@netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: dsahern@gmail.com, yhs@fb.com, ecree@solarflare.com, netdev@vger.kernel.org, oss-drivers@netronome.com To: Quentin Monnet , ast@kernel.org Return-path: Received: from www62.your-server.de ([213.133.104.62]:34276 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751574AbeEBPsb (ORCPT ); Wed, 2 May 2018 11:48:31 -0400 In-Reply-To: <20180502132024.14550-1-quentin.monnet@netronome.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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 Applied to bpf-next, thanks Quentin!