On Tue, Apr 02, 2024 at 09:00:45PM +0200, Björn Töpel wrote: > >> I still think Lehui's patch is correct; Building a kernel that can boot > >> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in > >> the kernel proper, and iff Zbb is available at run-time the BPF JIT will > >> emit Zbb. > > > > This sentence is -ENOPARSE to me, did you accidentally omit some words? > > Additionally he config option has nothing to do with building kernels that > > boot on multiple platforms, it only controls whether optimisations for Zbb > > are built so that if Zbb is detected they can be used. > > Ugh, sorry about that! I'm probably confused myself. Reading this back, I a bunch of words too, so no worries... > >> For these kind of optimizations, (IMO) it's better to let the BPF JIT > >> decide at run-time. > > > > Why is bpf a different case to any other user in this regard? > > I think that the commit message is misleading and needs to be changed, > > because the point "the hardware is capable of recognising the Zbb > > instructions independently..." is completely unrelated to the purpose > > of the config option. Of course the hardware understanding the option This should have been "understanding the instructions"... > > has nothing to do with kernel configuration. The commit message needs to > > explain why bpf is a special case and is exempt from an And this s/from an//... > > I totally understand any point about bpf being different in terms of > > needing toolchain support, but IIRC it was I who pointed out up-thread. And "pointed that out". I always make a mess of these emails that I re-write several times :) > > The part of the conversation that you're replying to here is about the > > semantics of the Kconfig option and the original patch never mentioned > > trying to avoid a dependency on toolchains at all, just kernel > > configurations. The toolchain requirements I don't think are even super > > hard to fulfill either - the last 3 versions of ld and lld all meet the > > criteria. > > Thanks for making it more clear, and I agree that the toolchain > requirements are not hard to fulfull. > > My view has been that "BPF is like userland", but I realize now that's > odd. Yeah, I can understand that perspective, but it does seem rather odd to someone that isn't a bpf-ist. > Let's make BPF similar to the rest of the RV kernel. If ZBB=n, then > the BPF JIT doesn't know about emitting Zbb.
Attachment:
signature.asc
Description: PGP signature
