Re: [PATCH 2.6.15.3 1/1] ACPI: Atlas ACPI driver

[Jaya Kumar]

On 2/20/06, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote:
> On Mon, Feb 20, 2006 at 06:49:54PM +0800, Jaya Kumar wrote:
>
> > I'm not sure how standard that is. For example, I looked at the asus
> > and toshiba drivers. These ACPI board drivers use
> > /proc/acpi/somedevice/lcd. For example,
>
> And, from a userspace perspective, it sucks. I'm in the process of
> writing patches to transition them all over, and I'd prefer not to have
> to write one for your driver as well :)

I have some questions then.
1. Are Patrick's acpi driver model changes considered to be a more
final approach that standardize everyone to some sysfs based interface
to userspace?
1a. Can I assume there is consensus among the acpi community around
his new model?
2. Is his driver model going to maintain compatibility with the older
existing /proc model and those userspace apps that already use that
interface?
3. Is his driver model going to also maintain compatibility with your
newer model (assuming that his model is different than yours).

>
> > I'll go take a look at that. I didn't look for an acpi driver outside
> > of the drivers/acpi directory. But if that's the consensus, shouldn't
> > someone also mod the toshiba and asus drivers?
>
> I'm doing so.

Ok. I wish I'd known before. I scanned the mailing list before
mbarking on this to see if any issues were raised with toshiba and
asus driver code and didn't see anything. FWIW, my powers of mind
reading only work on Fridays. :-)

> Doing it via the input layer adds flexibility - it makes it easier for
> non-root uesrspace to handle things, but you can still have a root-level
> daemon that monitors /dev/input/event* and runs commands in response to
> keycodes.
>

Oh. I don't disagree with that.

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