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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
