-
Notifications
You must be signed in to change notification settings - Fork 714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Project documentation website #1017
Conversation
102c907
to
e605539
Compare
bf6adae
to
f4b500d
Compare
24b997a
to
23ba515
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, and we should push it ASAP. Like I mentioned on our call, my main concern is that we nail down what kind of person we write for. As an example, some of the concepts pages explain both really basic Go things and "super advanced" finalizer stuff. I think that this makes the content less useful to both the less and the more advanced readers. In the best case we can build a "ladder" where our typical reader comes in and can go from basic to ever more complex pages.
I'd prefer if we'd start by writing for someone like this:
- A good grasp of the Go language, with an understanding of best practises. Able to write idiomatic Go. To me that implies being able to deal with os resources: read a file, open a socket.
- A basic grasp of C. Did some coding in uni or wherever. No need to explain the syntax of a function call or arithmetic.
- Prior knowledge of ebpf.io/what-is-ebpf.
- No knowledge of Go runtime internals.
- No knowledge of Linux kernel internals.
- No knowledge of C compiler specifics like magic macros, attributes, etc.
The first step in the ladder would be to get that person productive when using the lib. The second step would be to get that person ready to contribute.
2dce778
to
8c84560
Compare
Signed-off-by: Timo Beckers <[email protected]>
Explained in comments. Minimal impact to existing .c code, but makes rendered code blocks in markdown easier to read. Signed-off-by: Timo Beckers <[email protected]>
This allows docs and examples to depend on <bpf/bpf_helpers.h> and friends, reducing the amount of actions needed for newcomers to get up and running. Signed-off-by: Timo Beckers <[email protected]>
As of Go 1.21: go build ./... seems to build all main subpackages discarding output binaries. go test -c -o /dev/null also works as expected. Signed-off-by: Timo Beckers <[email protected]>
This commit introduces an mkdocs-based documentation boilerplate, containing: - The mkdocs configuration (mkdocs.yml), defining the site's navigation and ToC - Python dependency management using pipenv - Netlify configuration for automated builds & deploys - eBee emoji - Macros for easily including real code examples into documentation. These examples get built in CI, ensuring they don't rot when API or dependencies change. - A glossary for commonly-used terms in BPF land. - Custom admonition for rendering warnings about incomplete documentation sections using '!!! incomplete'. Signed-off-by: Timo Beckers <[email protected]>
Signed-off-by: Timo Beckers <[email protected]>
This patch adds deep-dives on ELF loading, object lifecycle, resource limits and ELF section naming. Illustrated by a few C and Go examples. Add a note to elf_reader.go to keep the ELF section prefix table up to date. Signed-off-by: Timo Beckers <[email protected]>
We want to write about bpf2go, BTF, feature probing, and working with maps and programs. Add a few writing prompts to help prospective authors to get started. Signed-off-by: Timo Beckers <[email protected]>
Signed-off-by: Timo Beckers <[email protected]>
This patch includes an override of a partial that supports hiding the title to create a nicer-looking landing page. Otherwise, mkdocs-material always renders an <h1> if we specify a custom <p> for a tagline graphic. Signed-off-by: Timo Beckers <[email protected]>
No description provided.