Generate docs for core and alloc locally
#129
Conversation
|
I think we still want to forbid not having docs everywhere (i.e. instead of writing it in the code), so we could use deny instead of forbid or, even better, keep the flag everywhere except for |
rust/Makefile
Outdated
| rustdoc: rustdoc-module rustdoc-compiler_builtins rustdoc-kernel | ||
| rustdoc: rustdoc-core rustdoc-module rustdoc-compiler_builtins rustdoc-alloc rustdoc-kernel | ||
|
|
||
| rustdoc-core: private skip_clippy = 1 |
There was a problem hiding this comment.
skip_clippy is not used for rustdoc. Did you add it for a particular reason?
There was a problem hiding this comment.
Sorry I didnt aware that. Fixed it!
There was a problem hiding this comment.
No need to say sorry! Thanks for working on this! :-)
|
I tested this, and it looks beautiful having However, many links inside So I am not sure what to do. I think it is better that links work vs. not supporting offline use. We could hack the links manually, though, but not sure how reliable that would end up being, and targeting the official webpage means it is one less thing to worry about, at least for the moment. Thoughts? |
|
I think this is more like upstream issues. Tested a bit, and I also found there are some would link to online docs ( |
|
Thinking about this a bit more, I would prefer that all the links work for the moment. In particular, since this will be shown to kernel developers new to Rust, they may be confused if they have never seen the standard library docs -- they may just think they are broken (rightfully so). In other words, I would prefer saying "we don't have offline support for Furthermore, if they actually need to go to the official page to read those docs anyway, they will need to be online anyway, so... I'm sorry because the PR is fine otherwise, and we will end up doing it at some point, but I think it would be a worse UX at the moment :-/ |
|
Another point is that, if I manage to upload this to kernel.org, then I expect many people will likely read it there vs. generating them on their own, so they would need online support anyway. |
|
Yeah, I tend to agree on this. I'll close this PR and let the docs stay as is. |
|
Thanks a lot for your work -- I am sorry we couldn't merge it. I will write what we found in #97 for the future. |
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL #119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL #120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL #121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL #122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL #123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL #124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL #125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL #126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL #127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL #128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL #129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL #130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL #486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Resolve #97
There are several places in
coreandallocusingallow(missing_doc)lint.And this is not compatible with
-Fmissing-docs.So I moved the lint to individual crates.