lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061213225452.GC20700@p15091797.pureserver.info>
Date:	Wed, 13 Dec 2006 23:54:52 +0100
From:	Ulrich Kunitz <kune@...ne-taler.de>
To:	Michael Wu <flamingice@...rmilk.net>
Cc:	Daniel Drake <dsd@...too.org>, netdev@...r.kernel.org,
	Johannes Berg <johannes@...solutions.net>
Subject: Re: [PATCH] zd1211rw-d80211: Use LED class

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists