On 7/31/24 1:18 AM, Ming Lei wrote:
On Tue, Jul 30, 2024 at 5:07 AM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote:
On 7/26/24 5:59 AM, Ming Lei wrote:
Almost all existed struct_ops users(hid, sched_ext, ...) need the two APIs.
In-tree hid-bpf code(drivers/hid/bpf/hid_bpf_struct_ops.c) can't be built
as module because the two APIs aren't exported.
The patch looks fine. I don't see "config HID_BPF" can be built as a module now
though that could expose this issue. Did I miss something?
Yeah, this patch doesn't try to change HID_BPF yet, and it can be thought
as one struct_ops module prep patch.
The issue itself is observed when I write ublk-bpf since ublk is one module
and struct_ops is allowed to be registered in the module.
Good to hear struct_ops find another potential use case. The ublk-bpf
development cannot continue without building as kmod?
Instead of exporting it now and pending without a user, I will wait till the
first in-tree kmod use case comes up first.
