Re: linux-next: Tree for July 30

On Thu, Jul 31, 2008 at 12:10:40PM -0700, Linus Torvalds wrote:

On Thu, 31 Jul 2008, Dmitry Torokhov wrote:

quoted

quoted

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.

quoted

quoted

 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.

quoted

quoted

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