On Wed, Feb 25, 2009 at 05:53:39PM +0000, Jonathan Buzzard wrote: > > On Wed, 2009-02-25 at 17:28 +0000, Matthew Garrett wrote: > > The same argument encourages us to put rfkill and brightness control > > support in a userland tool, despite the existing kernel interfaces for > > controlling them. We could replace almost every driver in platform/x86 > > with a generic driver that allowed arbitrary ACPI methods to be called > > and gave access to EC bits. The reason we haven't done this is because > > that's what the kernel is there for. > > Quite correct they should be removed. The first step of which is to > provide a generic interface to the HCI. Yeah. No. > You do it, test it then maintain it then. To claim that maintaining this > in kernel space is as easy as users space is patently ludicrous. How so? C is C. Whether you do it in userspace or kernel space, all you have to do is make a function call with the appropriate arguments. > A "proper" kernel driver as you put it is is completely inappropriate. > You want to unnecessarily pollute the kernel with hundreds of lines of > code for no actual gain in functionality. Yes. I want a proper kernel driver. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
