[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <170205722361.30055.15108519957098973880.git-patchwork-notify@kernel.org>
Date: Fri, 08 Dec 2023 17:40:23 +0000
From: patchwork-bot+netdevbpf@...nel.org
To: David Vernet <void@...ifault.com>
Cc: bpf@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
andrii@...nel.org, martin.lau@...ux.dev, song@...nel.org,
yonghong.song@...ux.dev, john.fastabend@...il.com,
kpsingh@...nel.org, sdf@...gle.com, haoluo@...gle.com,
jolsa@...nel.org, linux-kernel@...r.kernel.org,
kernel-team@...a.com, tj@...nel.org
Subject: Re: [PATCH bpf-next] bpf: Load vmlinux btf for any struct_ops map
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko <andrii@...nel.org>:
On Fri, 8 Dec 2023 00:17:03 -0600 you wrote:
> In libbpf, when determining whether we need to load vmlinux btf, we're
> currently (among other things) checking whether there is any struct_ops
> program present in the object. This works for most realistic struct_ops
> maps, as a struct_ops map is of course typically composed of one or more
> struct_ops programs. However, that technically need not be the case. A
> struct_ops interface could be defined which allows a map to be specified
> which one or more non-prog fields, and which provides default behavior
> if no struct_ops progs is actually provided otherwise. For sched_ext,
> for example, you technically only need to specify the name of the
> scheduler in the struct_ops map, with the core scheduler logic providing
> default behavior if no prog is actually specified.
>
> [...]
Here is the summary with links:
- [bpf-next] bpf: Load vmlinux btf for any struct_ops map
https://git.kernel.org/bpf/bpf-next/c/8b7b0e5fe47d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Powered by blists - more mailing lists