Re: [PATCHv2 bpf-next 13/15] selftests/bpf: Test syscall command parsing
From: Joe Stringer <hidden>
Date: 2021-03-04 01:00:03
Also in:
bpf, linux-doc
On Wed, Mar 3, 2021 at 2:23 PM Yonghong Song [off-list ref] wrote:
On 3/2/21 9:19 AM, Joe Stringer wrote:quoted
Add building of the bpf(2) syscall commands documentation as part of the docs building step in the build. This allows us to pick up on potential parse errors from the docs generator script as part of selftests. The generated manual pages here are not intended for distribution, they are just a fragment that can be integrated into the other static text of bpf(2) to form the full manual page.I tried and the generated bpf(2) man page looks like: BPF(2) BPF(2) NAME bpf - Perform a command on an extended BPF object COMMANDS BPF_MAP_CREATE Description Create a map and return a file descriptor that refers to the map. The close-on-exec file descriptor flag (see fcntl(2)) is automatically enabled for the new file descriptor. Applying close(2) to the file descriptor returned by BPF_MAP_CREATE will delete the map (but see NOTES). Return A new file descriptor (a nonnegative integer), or -1 if an error occurred (in which case, errno is set appropriately). BPF_MAP_LOOKUP_ELEM ... BPF_PROG_BIND_MAP Description Bind a map to the lifetime of an eBPF program. The map identified by map_fd is bound to the program identified by prog_fd and only released when prog_fd is released. This may be used in cases where metadata should be associated with a program which otherwise does not contain any references to the map (for example, embedded in the eBPF program instructions). Return Returns zero on success. On error, -1 is returned and errno is set appropriately. Yes, this needs to be integrated into the real man page. But this is already great so people can see latest bpf latest features without going to the source code. Thanks!
:party-parrot: Yeah I think the step around integrating into the real man page is an area that folks may have opinions on and I'm CC'ing Michael here in particular, but ultimately that manual is currently managed in the upstream manpages tree so nothing actionable from this series, absolute simplest is for someone (is that me?) to just package this hunk up and submit it to the upstream tree every once in a while. Slightly more elaborate would involve integrating the static text with this generated text somewhere (either kernel tree or manpages tree) and have someone run a cron job to generate & submit the changes. Could be another option, these are the obvious ones that come to mind.
quoted
Acked-by: Toke Høiland-Jørgensen <redacted> Reviewed-by: Quentin Monnet <redacted> Signed-off-by: Joe Stringer <redacted>Acked-by: Yonghong Song <redacted>