Re: Good first-time BPF tasks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/21/24 8:41 PM, Shung-Hsi Yu wrote:
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
Great list, thanks for compiling! I'd also add:

- Triaging & fixing open syzbot issues: https://syzkaller.appspot.com/upstream/s/bpf - Converting BPF selftests into test_progs style for tests which currently can only
  be run standalone. Once converted, the old ones can be removed.
- Converting BPF samples to BPF selftests into test_progs style. Same, once converted
  the old BPF samples should be removed.
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/





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux