All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: Jens Axboe <axboe@suse.de>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 10/11] LED: Add IDE disk activity LED trigger
Date: Tue, 31 Jan 2006 22:03:35 +0000	[thread overview]
Message-ID: <1138745015.6869.295.camel@localhost.localdomain> (raw)
In-Reply-To: <20060131203552.GG4215@suse.de>

On Tue, 2006-01-31 at 21:35 +0100, Jens Axboe wrote:
> Perhaps a generic solution isn't feasible, because this isn't really a
> generic problem. 

I agree. I think that email goes to show that totally generic led
triggers aren't achievable, desirable or useful.

> The LED stuff has very limited use - you mention
> embedded platforms, perhaps they should just be doing this on their own?

I am convinced the led class core and the led trigger *core* should be
in the mainline kernel. The alternative is for everyone to invent their
own versions and end up in a mess. The arm LED code is one example of
something done adhoc which no other arch can benefit from.

The core code doesn't touch anything outside of drivers/leds and can be
hidden behind any config options found to be appropriate.

> Generally I'm finding a hard time justifying an LED api, honestly. It
> just feels like one of those things where the actual abstraction ends up
> being a lot bigger than code needed. Abstracting and creating an API
> isn't always useful.

Nobody seems to have any issues with the led class or the led drivers
themselves. The triggers are the controversial aspect. The trigger API
is in a way too powerful as it can let you use anything as an LED
trigger. This leads to people asking for anything and everything as a
trigger.

Perhaps the best solution might be to allow the LED class core, the
triggers *core* and led drivers into the kernel but be extremely
selective about which triggers are allowed (if any). 

I think there is a case for including specific triggers like the sharpsl
charging trigger as if we're going to have sharpsl charging code in the
kernel (which we have), it might as well connect up to the charging led
it was built for.

If all other more generic triggers are rejected, I can live with that.
Maintaining a handful of trigger patches outside the kernel, most of
them a few lines long is much easier than maintaining a whole subsystem.

Would that be acceptable?

Richard


  parent reply	other threads:[~2006-01-31 22:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-31 13:41 [PATCH 10/11] LED: Add IDE disk activity LED trigger Richard Purdie
2006-01-31 14:46 ` Bartlomiej Zolnierkiewicz
2006-01-31 16:21   ` Richard Purdie
2006-01-31 17:44     ` Bartlomiej Zolnierkiewicz
2006-01-31 20:29       ` Jens Axboe
2006-01-31 22:08       ` Benjamin Herrenschmidt
2006-01-31 23:39         ` Richard Purdie
2006-02-04 15:29       ` Richard Purdie
2006-01-31 20:35     ` Jens Axboe
2006-01-31 21:22       ` Jordan Crouse
2006-02-01  0:12         ` Matt Reimer
2006-02-02  1:32         ` Adrian Bunk
2006-01-31 22:03       ` Richard Purdie [this message]
2006-02-02 11:07       ` [PATCH 10/11] " Pavel Machek
2006-02-01 16:09 ` Jan Engelhardt
2006-02-04  9:54   ` Jan-Benedict Glaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1138745015.6869.295.camel@localhost.localdomain \
    --to=rpurdie@rpsys.net \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.