linux-kernel - Re: GFS2: Add LED support to GFS2

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: <1248882732.3298.142.camel@localhost.localdomain>
Date:	Wed, 29 Jul 2009 16:52:12 +0100
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	Pavel Machek <pavel@....cz>
Cc:	cluster-devel@...hat.com, linux-kernel@...r.kernel.org,
	rpurdie@...ys.net
Subject: Re: GFS2: Add LED support to GFS2

Hi,

On Wed, 2009-07-29 at 17:08 +0200, Pavel Machek wrote:
> On Wed 2009-07-22 11:56:38, Steven Whitehouse wrote:
> > >From e1fac35b9c2af276473db50fae581ef56626240c Mon Sep 17 00:00:00 2001
> > From: Steven Whitehouse <swhiteho@...hat.com>
> > Date: Wed, 22 Jul 2009 11:40:16 +0100
> > Subject: [PATCH] GFS2: Add LED support to GFS2
> > 
> > This adds a standalone module which uses the GFS2 tracepoints
> > as a hook to provide LED trigger events. Events can be sent
> > when glocks change state, when glock demote requests are
> > received (both local and remote events are included) and also
> > when the log is flushed.
> > 
> > The log flush event lights the LED during the duration of the
> > log flush event. The other two triggers light the LED for 1/10th
> > second after the event has occurred.
> > 
> > I've tested this by using GFS2 in "nolock" mode on my laptop
> > by getting it to flash the thinkpad battery LED on the various
> > events and verified that it occurs when expected.
> 
> This looks way too specialized to me. Yes, it will be pretty,
> but... there's about 100000 possible triggers. Where do we draw a
> line? Or do we merge all of them?
> 								Pavel

There might be a lot of possible triggers, but that doesn't mean there
are actually a lot of actual triggers. Surely what makes the LED
subsystem useful is that is can show a wide variety of events?

If there is an issue, then it seems to me, its the way in which we
enumerate the events, not that there are "too many" per se. If you have
a rack of machines in a data center it might be very useful to be able
to instantly check the visual status of an important parameter using the
LEDs. Likewise it would be similarly useful if someone was to use GFS2
in an embedded environment where LEDs are often the sum total of the
user interface.

Whether or not it is merged ought to be down to whether it affects
anything else (which is doesn't as it is self-contained) whether the
code is maintainable, and whether it makes sense as a feature I think.

Steve.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/