From: Lee Jones <lee@kernel.org>
To: Daniel Hodges <hodges.daniel.scott@gmail.com>
Cc: ast@kernel.org, bpf@vger.kernel.org, daniel@iogearbox.net,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
pavel@ucw.cz
Subject: Re: [PATCH v2 1/3] leds: trigger: legtrig-bpf: Add ledtrig-bpf trigger
Date: Thu, 11 Apr 2024 11:40:07 +0100 [thread overview]
Message-ID: <20240411104007.GC1980182@google.com> (raw)
In-Reply-To: <da92268495053af38f6ae8e8efb12ceec0947130.1711415233.git.hodges.daniel.scott@gmail.com>
On Mon, 25 Mar 2024, Daniel Hodges wrote:
> This patch adds a led trigger that interfaces with the bpf subsystem. It
> allows for BPF programs to control LED activity through calling bpf
> kfuncs. This functionality is useful in giving users a physical
> indication that a BPF program has performed an operation such as
> handling a packet or probe point.
>
> Signed-off-by: Daniel Hodges <hodges.daniel.scott@gmail.com>
> ---
> drivers/leds/trigger/Kconfig | 10 ++++
> drivers/leds/trigger/Makefile | 1 +
> drivers/leds/trigger/ledtrig-bpf.c | 73 ++++++++++++++++++++++++++++++
> 3 files changed, 84 insertions(+)
> create mode 100644 drivers/leds/trigger/ledtrig-bpf.c
>
> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
> index d11d80176fc0..30b0fd3847be 100644
> --- a/drivers/leds/trigger/Kconfig
> +++ b/drivers/leds/trigger/Kconfig
> @@ -152,4 +152,14 @@ config LEDS_TRIGGER_TTY
>
> When build as a module this driver will be called ledtrig-tty.
>
> +config LEDS_TRIGGER_BPF
> + tristate "LED BPF Trigger"
> + depends on BPF
> + depends on BPF_SYSCALL
> + help
> + This allows LEDs to be controlled by the BPF subsystem. This trigger
> + must be used with a loaded BPF program in order to control LED state.
> + BPF programs can control LED state with kfuncs.
> + If unsure, say N.
> +
> endif # LEDS_TRIGGERS
> diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
> index 25c4db97cdd4..ac47128d406c 100644
> --- a/drivers/leds/trigger/Makefile
> +++ b/drivers/leds/trigger/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_LEDS_TRIGGER_NETDEV) += ledtrig-netdev.o
> obj-$(CONFIG_LEDS_TRIGGER_PATTERN) += ledtrig-pattern.o
> obj-$(CONFIG_LEDS_TRIGGER_AUDIO) += ledtrig-audio.o
> obj-$(CONFIG_LEDS_TRIGGER_TTY) += ledtrig-tty.o
> +obj-$(CONFIG_LEDS_TRIGGER_BPF) += ledtrig-bpf.o
> diff --git a/drivers/leds/trigger/ledtrig-bpf.c b/drivers/leds/trigger/ledtrig-bpf.c
> new file mode 100644
> index 000000000000..99cabf816da4
> --- /dev/null
> +++ b/drivers/leds/trigger/ledtrig-bpf.c
> @@ -0,0 +1,73 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * LED BPF Trigger
> + *
> + * Author: Daniel Hodges <hodges.daniel.scott@gmail.com>
Any copyright?
> + */
> +
> +#include <linux/bpf.h>
> +#include <linux/btf.h>
> +#include <linux/btf_ids.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/leds.h>
> +#include <linux/module.h>
> +#include <linux/rcupdate.h>
> +
> +
> +DEFINE_LED_TRIGGER(ledtrig_bpf);
> +
> +__bpf_kfunc_start_defs();
__bpf_hook_start()?
> +__bpf_kfunc void bpf_ledtrig_blink(const char *led_name__str, unsigned long
> + delay_on, unsigned long delay_off, int invert)
Nit: Try to keep the variable types and names together please.
I.e. break before the 'unsigned' or after 'delay_on'.
> +{
> + struct led_classdev *led_cdev;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(led_cdev, &ledtrig_bpf->led_cdevs, trig_list) {
> + if (strcmp(led_name__str, led_cdev->name) == 0) {
> + led_blink_set_oneshot(led_cdev, &delay_on, &delay_off,
> + invert);
Use 100-chars to avoid the break.
> + break;
> + }
> + }
> + rcu_read_unlock();
> +}
> +__bpf_kfunc_end_defs();
_bpf_hook_end()?
> +BTF_KFUNCS_START(ledtrig_bpf_kfunc_ids)
> +BTF_ID_FLAGS(func, bpf_ledtrig_blink, KF_TRUSTED_ARGS)
> +BTF_KFUNCS_END(ledtrig_bpf_kfunc_ids)
Why not a single macro to output the full struct?
Or better yet, be less opaque and not use a macro at all?
> +static const struct btf_kfunc_id_set ledtrig_bpf_kfunc_set = {
> + .owner = THIS_MODULE,
> + .set = &ledtrig_bpf_kfunc_ids,
> +};
> +
> +static int init_bpf(void)
> +{
> + int ret;
> +
> + ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_UNSPEC,
> + &ledtrig_bpf_kfunc_set);
> + return ret;
return register_btf_kfunc_id_set()?
Or again, better yet, put the single function call directly into
ledtrig_bpf_init()? Creating a whole function just for a single
invocation seems superfluous.
> +}
> +
> +static int __init ledtrig_bpf_init(void)
> +{
> + led_trigger_register_simple("bpf", &ledtrig_bpf);
> +
> + return init_bpf();
> +}
> +
> +static void __exit ledtrig_bpf_exit(void)
> +{
> + led_trigger_unregister_simple(ledtrig_bpf);
> +}
> +
> +module_init(ledtrig_bpf_init);
> +module_exit(ledtrig_bpf_exit);
> +
> +MODULE_AUTHOR("Daniel Hodges <hodges.daniel.scott@gmail.com>");
> +MODULE_DESCRIPTION("BPF LED trigger");
> +MODULE_LICENSE("GPL v2");
> --
> 2.43.2
>
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2024-04-11 10:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 14:08 [PATCH 0/3] leds: trigger: Add led trigger for bpf Daniel Hodges
2024-03-22 14:08 ` [PATCH 1/3] leds: trigger: legtrig-bpf: Add ledtrig-bpf module Daniel Hodges
2024-03-22 15:24 ` Yonghong Song
2024-03-22 21:52 ` Pavel Machek
2024-03-23 19:19 ` Alexei Starovoitov
2024-03-27 1:53 ` Daniel Hodges
2024-03-23 22:25 ` Andrew Lunn
2024-03-23 22:18 ` Andrew Lunn
2024-03-24 2:15 ` Daniel Hodges
2024-03-24 2:15 ` Daniel Hodges
2024-03-26 1:14 ` [PATCH v2 0/3] leds: trigger: legtrig-bpf: Add ledtrig-bpf trigger Daniel Hodges
2024-03-26 1:14 ` [PATCH v2 1/3] " Daniel Hodges
2024-04-11 10:40 ` Lee Jones [this message]
2024-03-26 1:14 ` [PATCH v2 2/3] selftests/bpf: Add selftests for bpf led programs Daniel Hodges
2024-03-26 1:14 ` [PATCH v2 3/3] leds: trigger: Add documentation for ledtrig-bpf Daniel Hodges
2024-04-11 10:46 ` Lee Jones
2024-03-22 14:08 ` [PATCH 2/3] selftests/bpf: Add selftests for bpf led programs Daniel Hodges
2024-03-22 14:08 ` [PATCH 3/3] leds: trigger: Add documentation for ledtrig-bpf Daniel Hodges
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240411104007.GC1980182@google.com \
--to=lee@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hodges.daniel.scott@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.