Subject: Re: [SoC] LED/LCD Generic API
To: None <firstname.lastname@example.org>
From: Joseph Mullally <email@example.com>
Date: 05/07/2006 05:35:07
I get ya. In that case here is a revised proposal which impliments the wi=
a kernel device instead of a daemon. The suggestion of using gpio devices=
output indicators is in there aswell.
Thanks for the feedback so far btw, its greatly appreciated!
Quoting Michael Lorenz <firstname.lastname@example.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> >> With regards to Summer of Code projects, I am very interested in
> >> the "LED/LCD
> >> Generic API" project. While I realise its cutting it close for this,
> >> if anyone
> >> has any feedback on my proposal that would be great. The proposal is
> >> at
> >> http://www.netsoc.tcd.ie/~bofh/soc_NetBSD_LEDAPI.html
> >> Thanks!
> >> -- Joseph Mullally
> > Hmm... I really like the idea of a common API. But I am doubtful abo=
> > the need or benefit provided by a userland daemon. Couldn't this
> > instead be handled by simple ioctls to the devices themselves, which
> > could export a common set of ioctls for querying features, and
> > getting/setting values?
> Seconded. Sure, a userland daemon would add flexibility but it would
> also add considerable overhead and would be useless during kernel
> startup when LEDs/LCDs might be a valuable debugging aid.
> Same about kernel panics.
> > A *utility* that runs at startup to configure initial settings from
> > some
> > configuration file might be useful however.
> Definitely, it may not always be possible to come up with a reasonable
> and complete default wiring and this default may or may not be what the
> user wants.
> > I would strongly recommend looking at the GPIO framework as an exampl=
> > for what I have in mind.
> Yes, it would be nice if we could use any gpio as output.
> > I'd also be willing to mentor this project.
> I've been volunteered for it as well ;)
> have fun
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> -----END PGP SIGNATURE-----