[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240324021811.20794-1-hodges.daniel.scott@gmail.com>
Date: Sat, 23 Mar 2024 22:15:01 -0400
From: Daniel Hodges <hodges.daniel.scott@...il.com>
To: andrew@...n.ch
Cc: ast@...nel.org,
bpf@...r.kernel.org,
daniel@...earbox.net,
hodges.daniel.scott@...il.com,
lee@...nel.org,
linux-kernel@...r.kernel.org,
linux-leds@...r.kernel.org,
pavel@....cz
Subject: Re: [PATCH 1/3] leds: trigger: legtrig-bpf: Add ledtrig-bpf module
> On Fri, Mar 22, 2024 at 10:08:14AM -0400, 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.
>
> Don't you want a mechanism to say which LED it should blink? Say you
> have a BPF IR receiver, a BPF kernel scheduler and a BPF firewall. All
> sharing the same LED is probably not what you want. Each probably
> wants its own LED.
>
> Andrew
Yeah, I think that makes sense. I guess the idea with this patch set was
more or less to show the simple implementation. Since there can be
multiple devices the trigger probably needs a registry of the active
led_classdev names or other id. Alexei mentioned the xt_led which looks
like it is rather similar as well. I can give this another shot, but I
didn't want to go too far down the rabbit hole without getting some
signal on the idea in general.
PS Sorry to folks if I've directly replied to your comments. I'm still in the
process of setting up my email workflow.
- Daniel
Powered by blists - more mailing lists