On Wed, Feb 25, 2009 at 05:12:58PM +0000, Jonathan Buzzard wrote: > Surely a consistent abstraction of the HCI interface with a user mode > program to tickle that interface as necessary is better than adding > hundreds of lines of code to the kernel, and having to constantly update > the driver when new models come out? 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. > On top of that this is the way it has been done now for over a decade. > The patch enables modern ACPI laptops to use the existing tools for > Toshiba laptops, without having to compile your own out of band kernel > module. It is unlikely that someone is going to write and debug the > kernel code to move the likes of toshset into kernel space in the first > place and keep it up to date in the second. The effort required to maintain toshset is identical to the effort required to maintain the kernel-level driver. Porting this functionality isn't difficult. Please don't add an interface that exists purely in order to avoid writing 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
