Michael, please detach a little bit from LEDs.
A trigger is a generic concept. It doesn't need to have a special binding to what it triggers. It could be a buzzer, it could be an LED, it could be text output on an LCD. So we could have link status change trigger, for which functions could be registered. There is no reason for the upper layer d80211 code to know, that it triggers an LED. A netlink event generator could only be one of the users of those generic triggers. My other opinion is that I find it overkill to handle the LED on a WLAN adapter as an independent device instantiating a device class in Linux. I mean on the other hands we break APIs for four or eight bytes and here we spend a whole device strucuture and sysfs directory for something the wlan device firmware represents with a single bit. To call the housekeeping functions overkill under these circumstances appears not to be very rational. It should also be mentioned that the LEDs on the ZD1211 devices are not independent devices, because they are partly controlled by the firmware. That's exactly where some of the issues with your patch are. Let the device drivers do the blinking, but give them a chance to know about status changes at the MAC layer, without mandating to implement a LED device. Using the same triggers by a netlink event generator, would make the code even simpler. -- Uli Kunitz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
