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