Matthew Garrett wrote:
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.
Yeah, yes
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.
No it is not. C that is running in kernel space is not the same as C
that is runing in user space. The potential for a bug to have security
implications is *far* higher. If you start pushing hundreds of lines of
string parsing into the kernel that just got a whole lot more likely.
Then one has to go through the whole rigmarole of submitting patches to
various kernel developers and hoping that it gets in the next kernel. As
opposed to releasing your own user land code, that might not even be in
C, it could be C++, Perl, Python whatever takes your fancy when ever it
takes your fancy.
Finally I speak from actual experience on this matter. The very early
versions of the toshiba drive did everything via a proc interface. It
sucked, was buggy and hundreds of lines long. I then stripped it down
wrote a wrapper to the HCI, reduced the amount of kernel code by an
order of magnitude.
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.
Well write it yourself, because I certainly am not. In the meantime
there is perfectly good method that allows lots of existing code to just
work. The only thing I am likely to do is update the toshiba driver so
it detects whether ACPI is enabled and uses ACPI methods if that is the
case.
I would be interested in what on earth makes you thing putting hundreds
of lines of code into a "proper" kernel driver as you put it is better
as it is simply not the Unix way.
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
