On 31/01/06 21:35 +0100, "Jens Axboe" wrote:
> Perhaps a generic solution isn't feasible, because this isn't really a
> generic problem. The LED stuff has very limited use - you mention
> embedded platforms, perhaps they should just be doing this on their own?
Possibly, but what you'll find is that many different embedded platforms
end up wanting similar behavior, and if they all do it on their own, that
ends up in a mess.
Take the Alchemy platform for example - we have a bank of LEDs at our
disposal, and we too would like to use them to do very similar things
as the ARM/Xscale folks - things like show IDE/SD/MTD traffic, or the
status of a battery. Rather then go in and hack that stuff in ourselves,
I would much rather just define a few API hooks and getting the rest for
free (or really cheap).
Perhaps it can be hidden behind a CONFIG_EMBEDDED or something so that
the desktop platforms aren't bothered by it, but speaking for the two
embedded platforms I'm attached to, my vote for this LED class is a "yes".
--
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
