On Wed, 2009-02-25 at 16:51 +0000, Matthew Garrett wrote: > On Wed, Feb 25, 2009 at 04:18:25PM +0000, Jonathan Buzzard wrote: > > > Because it makes far more sense to have a user mode program to drive the > > features, and for the kernel to provide the necessary thin layer to > > access the features. > > It makes sense for the kernel to provide a consistent abstraction of > hardware functionality where possible. Almost every kernel driver could > be rewritten in userspace - that doesn't make it a good idea. > The driver *does* provide a consistent abstraction of the Toshiba Hardware Configuration Interface (HCI) on an ACPI enabled "pucker" Toshiba laptop, that is a laptop designed and manufactured by Toshiba and not OEM'ed. That patch causes the toshiba_acpi driver to provide the same abstraction of the HCI that the toshiba driver provides for "pucker" Toshiba laptops with APM and has been doing so for over a decade now. The HCI interface has existed on "pucker" Toshiba laptops for a very long time, nearly 20 years now. The calls that are valid in the HCI are specific to the model in question. 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? 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. JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Fife, United Kingdom. -- 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