On Fri, Jul 15, 2022 at 7:02 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Jul 12, 2022 at 04:58:39PM +0200, Benjamin Tissoires wrote: > > --- /dev/null > > +++ b/drivers/hid/bpf/Kconfig > > @@ -0,0 +1,19 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +menu "HID-BPF support" > > + #depends on x86_64 > > + > > +config HID_BPF > > + bool "HID-BPF support" > > + default y > > Things are only default y if you can't boot your machine without it. > Perhaps just mirror what HID is to start with and do not select HID? > > > + depends on BPF && BPF_SYSCALL > > + select HID > > select is rough, why not depend? Let me try to explain this mess, maybe you can give me the piece that I am missing: The requirements I have (or want) are: - HID-BPF should be "part" of HID-core (or something similar of "part"): I intend to have device fixes as part of the regular HID flow, so allowing distros to opt out seems a little bit dangerous - the HID tree is not as clean as some other trees: drivers/hid/ sees both core elements and leaf drivers transport layers are slightly better, they are in their own subdirectories, but some transport layers are everywhere in the kernel code or directly in drivers/hid (uhid and hid-logitech-dj for instance) - HID can be loaded as a module (only ubuntu is using that), and this is less and less relevant because of all of the various transport layers we have basically prevent a clean unloading of the module These made me think that I should have a separate bpf subdir for HID-BPF, to keep things separated, which means I can not include HID-BPF in hid.ko directly, it goes into a separate driver. And then I have a chicken and egg problem: - HID-core needs to call functions from HID-BPF (to hook into it) - but HID-BPF needs to also call functions from HID-core (for accessing HID internals) I have solved that situation with struct hid_bpf_ops but it is not the cleanest possible way. And that's also why I did "select HID", because HID-BPF without HID is pointless. One last bit I should add. hid-bpf.ko should be allowed to be compiled in as a module, but I had issues at boot because kfuncs were not getting registered properly (though it works for the net test driver). So I decided to make hid-bpf a boolean instead of a tristate. As I type all of this, I am starting to wonder if I should not tackle the very first point and separate hid-core in its own subdir. This way I can have a directory with only the core part, and having hid-bpf in here wouldn't be too much of an issue. Thoughts? Cheers, Benjamin
