Re: experimental patch for toshiba_acpi

[Jonathan Buzzard <jonathan@buzzard.me.uk>]

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.