A topic that came up several times off-list at LPC was how to start
contributing to the BPF subsystem. One of the thing that would probably help
is to have a list of todos that are nice to have and can be implemented in a
relatively self-contained set of patches. Here's things that I've gathered.
On the more concrete task sides (easy to hard):
- Check return value of btf__align_of() in btf_dump_emit_struct_def()
- Replace open-coded & PTR_MAYBE_NULL checks with type_may_be_null()
- Implement tnum_scast(), and use that to simply var_off induction in
coerce_reg_to_size_sx()
- Better error message when BTF generation failed, or at least fail earlier
- Refactor to use list_head to create a linked-list of bpf_verifier_state
instead of using bpf_verifier_state_list
On the more general side of things:
- Improve the documentation
- add the missing pieces (e.g. document all BPF_PROG_TYPE_*)
- update the out-date part (admittedly quite hard)
- Improve the BPF selftests coverage
- add test for fixes that have been merged but does not come with a
corresponding test case to prevent regression
I want to keep the list from being too verbose, so I won't go into too
much detail in this email. But feel free to reply to this thread and
ask. You might want to use https://github.com/sjp38/hackermail to reply
if you're not familiar with mailing lists.
(I know mailing list don't have the best UX, is a scary place, and also
not the best issue tracker, we'll see how this works out and change if
needed)
Also If anyone has other things they want to add to the list that will
be great.
The most probably outcome is nobody replies, and I stop doing this after
a few months. But still, worth a try and the only thing that gets hurt
in this process is my ego ;)
---
Expectations
You should have a relatively solid idea about C (pointers, memory
layout, undefined behavior, etc.). That is not to say you cannot make
any mistake (we all do), just that mailing list is not the best place
to receive an entire lecture on C.
Personally I would also recommend to familiar yourself on open source
contribution, elsewhere first.
You will be doing 99% of the work and have to spend a great deal of
time reading code to try understand how things works before you can
write you first line of code, and at that point you're probably only
10% done.
Disclaimer
Maintainers have the final say on whether things gets merged or not.
And Sometimes things that seems like a good idea at first may turnout
to be undesired; so there's no guarantee that all the hard work you
poured in will land. Additionally the task may turned out to have
hidden complexity, making it a not so good first time task, but only
to be know afterwards.
Resources
- Introduction to BPF selftests
https://lore.kernel.org/bpf/62b54401510477eebdb6e1272ba4308ee121c215.camel@xxxxxxxxx/
