From: Donald Hunter <donald.hunter@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: bpf@vger.kernel.org, linux-doc@vger.kernel.org,
Andrii Nakryiko <andrii.nakryiko@gmail.com>
Subject: Re: [PATCH bpf-next v4 1/2] Add subdir support to Documentation makefile
Date: Fri, 23 Sep 2022 15:58:14 +0100 [thread overview]
Message-ID: <m2h70y87eh.fsf@gmail.com> (raw)
In-Reply-To: <87tu4zsfse.fsf@meer.lwn.net> (Jonathan Corbet's message of "Thu, 22 Sep 2022 07:24:33 -0600")
Jonathan Corbet <corbet@lwn.net> writes:
> Donald Hunter <donald.hunter@gmail.com> writes:
>
>> Run make in list of subdirs to build generated sources and migrate
>> userspace-api/media to use this instead of being a special case.
>>
>> Signed-off-by: Donald Hunter <donald.hunter@gmail.com>
>
> This could really use a bit more information on exactly what you're
> doing and why you want to do it.
What would you like me to add? Something like:
"... in preparation for running a generator script to produce .csv data
used by bpf documentation"
> Beyond that, I would *really* like to see more use of Sphinx extensions
> for this kind of special-case build rather than hacking in more
> special-purpose scripts. Is there a reason why it couldn't be done that
> way?
I looked at writing the BPF program types as a Sphinx extension but
found that approach problematic for the following reasons:
- This needs to run both in the kernel tree and the libbpf Github
project. The tree layouts are different so the relative paths to
source files are different. I don't see an elegant way to handle this
inline in a .rst file. This can easily be handled in Makefiles
that are specific to each project.
- It makes use of csv-table which does all the heavy lifting to produce
the desired output.
- I have zero experience of extending Sphinx.
I thought about submitting this directly to the libbpf Github project
and then just linking from the kernel docs to the page about program
types in the libbpf project docs. But I think it is preferable to master
the gen-bpf-progtypes.sh script in the kernel tree where it can be
maintained in the same repo as the libbpf.c source file it parses.
next prev parent reply other threads:[~2022-09-23 15:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-22 11:52 [PATCH bpf-next v4 0/2] Add table of BPF program types to docs Donald Hunter
2022-09-22 11:52 ` [PATCH bpf-next v4 1/2] Add subdir support to Documentation makefile Donald Hunter
2022-09-22 13:24 ` Jonathan Corbet
2022-09-23 14:58 ` Donald Hunter [this message]
2022-09-30 9:57 ` Donald Hunter
2022-09-30 22:25 ` Andrii Nakryiko
2022-09-22 11:52 ` [PATCH bpf-next v4 2/2] Add table of BPF program types to libbpf docs Donald Hunter
2022-09-23 13:22 ` Bagas Sanjaya
2022-09-23 15:05 ` Donald Hunter
2022-09-26 1:33 ` Bagas Sanjaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2h70y87eh.fsf@gmail.com \
--to=donald.hunter@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.