On Thu, Jul 31, 2008 at 12:10:40PM -0700, Linus Torvalds wrote: > > > On Thu, 31 Jul 2008, Dmitry Torokhov wrote: > > > > > > Well, we're not supposed to break user space that we used to work with, even > > > if it is known to be buggy. > > > > No, I am sorry. We are not supposed to break userspace ABI, but that > > is it. Can you vouch that 2.6.25 did not break a single userspace > > program out there? > > Dmitry - irrelevant. If we know of breakage, then that is a FACT, and it's > a regression, and it needs to be fixed. Does it have to be papered over in the kernel though? > > Trying to say "there might be _other_ breakage that we don't even know of" > does not change the situation ONE LITTLE BIT! > > Don't you see how stupid that approach is? You're basically trying to make > excuses for known breakage by saying that there might be _other_ breakage > that we don't know about? Why the _hell_ do you think that is an excuse at > all? 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. > > > > Many people use the older user space on their > > > test systems which are not practical to upgrade. > > > > I don't understand this - it is expected that everyone jumps and > > upgrades their kernels with ease but updating broken userspace > > bits is super-hard... > > You're missing the point. > > People are supposed to be able to upgrade things _independently_. It's not > about "you're supposed to be able to upgrade the kernel, but not upgrade > user space". It's about "you shouldn't evemn have to _worry_ about it. > > > > IOW, if the change responsible for this makes it to the mainline kernel, it > > > will be considered as a regression. > > > > Like I said, I don't agree. > > Sorry, but you're simply wrong. > > If somebody has the commit that broke user space, that commit will be > _reverted_ unless it's fixed. It's that simple. The rules are: we don't > knowingly break user space. > 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). Gioventhe fact that I wanted that change to go when .28 opens and it will really hit users in 6+ months I'd still like to have 3. -- Dmitry -- 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
