|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Dmitry Torokhov <dmitry.torokhov-AT-gmail.com>|
|| ||Re: linux-next: Tree for July 30|
|| ||Thu, 31 Jul 2008 12:44:04 -0700 (PDT)|
|| ||"Rafael J. Wysocki" <rjw-AT-sisk.pl>,
Andrew Morton <akpm-AT-linux-foundation.org>,
Bartlomiej Zolnierkiewicz <bzolnier-AT-gmail.com>,
Stephen Rothwell <sfr-AT-canb.auug.org.au>,
linux-next-AT-vger.kernel.org, LKML <linux-kernel-AT-vger.kernel.org>,
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.
> 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
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.
(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
- a year down the line, maybe breakage will be a non-issue.
- 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?
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)