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.mon...@netronome.com>
Applied to bpf-next, thanks Quentin!
