The blinking and extinction of LED lights have also become an iptables target, powerful sweat, and lediptables

The blinking and extinction of LED lights have also become an iptables target, powerful sweat, and lediptables
As long as a data packet that complies with the rules arrives, the LED light will be XY. How can this effect be achieved?
There are many ways to do this: Use LOG target to send kernel logs, intercept rsyslogd, redirect to filter, and call shell to operate LED lights. Although it is very difficult, isn't it true that UNIX does not advocate this?
What is the most direct solution? I think it should be to write an event target, and report this packet to the user space through netlink as long as it matches. With this event target, even logs can be distributed through the listen daemon of the user space. After all, the information generated by the printk is not obtained through the syslog system call to obtain the syslog daemon?
It is hard to figure out why we need to go to the process event in the kernel. Is it just because it is easier to maintain timer? In addition, the name acquisition is not good. I think this problem is serious, although it does not affect the function. Even if I can design a kernel-state event mechanism to trigger and process events, I will not assume that this mechanism is associated with any specific object. The receiver of the event can of course be an LED light, but cannot it be a horn or a power supply?