Re: linux-next: Tree for July 30

Dmitry Torokhov
2008-07-31T19:24:26Z

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