Re: linux-next: Tree for July 30

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Thu, Jul 31, 2008 at 12:44:04PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> > 
> > Does it have to be papered over in the kernel though?
> 
> Yes. It's how we have worked. Asking people to upgrade big core programs 
> is not reasonable.
>
> Think of it this way: we absolutely _want_ people to run the latest 
> kernel. We want it for their own sake (security etc fixes), but we want it 
> even more for *our* own sake (testing, fixes etc).
> 
> And if we want to encourage people to upgrade their kernel very 
> aggressively (and we absolutely do!), then that means that we have to also 
> make sure it doesn't require them upgrading anything else.

Sometimes we do need to upgrade userspace though. Can we make
Documentation/Changes more prominent? Maybe have it published on
kernel.org?

> 
> > We can only guarantee one thing - ABI. And that is kept intact. But I
> > literally have no idea if a kernel breaks a random program out there
> > that happens to have a bug.
> 
> There are gray areas, yes. For example, timing changes do mean that a new 
> kenrel can easily break a program that used to work. We cannot handle 
> _everyting_. 
> 
> But when the ABI in question is some very specific one, that some 
> important program uses (even if the "uses" is "misuses") then it really 
> isn't a gray area any more.
> 
> And quite frankly, the ABI was apparently pretty bad to begin with, if 
> user space got an array back but didn't get to specify the size. So you 
> may want to say that user space was broken, but on the other hand, it's 
> equally arguable that the ABI was crap.

It did specify the size. Something 448 more bytes than it allocated:

    unsigned long evbits[NBITS(KEY_MAX)];

    /* Check for ABS_X, ABS_Y, ABS_PRESSURE and BTN_TOOL_FINGER */

    SYSCALL(ret = ioctl(fd, EVIOCGBIT(0, KEY_MAX), evbits));

So we allocate 64 bytes on stack and then as kernel to fill it with
511 bytes worth of data.

> 
> (Which is something you can pretty much take for granted with ioctl's, of 
> course. DO NOT CHANGE IOCTL'S. EVER!)
> 
> > We have 3 options now:
> > 
> > 1. Never change KEY_MAX and dont add any new key definitions.
> > 2. Introduce a new ioctl and have all wel-behaving programs rewritten
> >    to support it.
> > 3. Fix userspace driver (patch is available).
> 
> You ignore the obvious choice, which is how we _usually_ do it:
> 
>  - help fix up the userspace driver regardless

In progress.
> 
>  - a year down the line, maybe breakage will be a non-issue.
>

Around when 2.6.28 is released, right? ;)
 
>  - but at least _think_ about the fact that yes, most ioctl interfaces are 
>    pure and utter sh*t, and the problem was probably not so much the user 
>    space driver as the crap interface to begin with!
> 
> and discuss whether KEY_MAX really needs to be changed that much. I 
> suspect that the change was done without even realizing just how painful 
> it was, and that if you look at the original reason for it with the 
> hindsight of knowing that it was painful, maybe it wasn't that critical to 
> do it after all?
>

We do need more keycodes. People are coming wioth more and more. The
patch following the one in question adds about 10 new kodes for remote
controls/phones. And we will get more.

-- 
Dmitry