Re: linux-next: Tree for July 30

Linus Torvalds
2008-07-31T20:20:41Z

On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
>
> Sometimes we do need to upgrade userspace though. Can we make
> Documentation/Changes more prominent? Maybe have it published on
> kernel.org?

We basically _never_ have to upgrade userspace that aggressively. We can
have a Changes file that talks about things that will eventually break
when we remove support for it eventually, but it should never EVER be used
as an excuse for "I needed to break it now".

So no, I refuse to make it any more prominent. Because it would just be
used as an excuse for behavior that I consider unacceptable. It was
different back when we had 3-year development windows and people upgrading
from 2.4.x to 2.6.x had to learn new things, but for 2.6.26 to .27 or
similar it's simply not acceptable.

Look at the VFS layer. Look at how we have multiple different versions of
"readdir()" (well, getdents, really), and "stat()". Exactly because we
don't break user space.

> It did specify the size. Something 448 more bytes than it allocated:
>
> unsigned long evbits[NBITS(KEY_MAX)];
>
> /* Check for ABS_X, ABS_Y, ABS_PRESSURE and BTN_TOOL_FINGER */
>
> SYSCALL(ret = ioctl(fd, EVIOCGBIT(0, KEY_MAX), evbits));
>
> So we allocate 64 bytes on stack and then as kernel to fill it with
> 511 bytes worth of data.

Ok, I can see how it's confused, asking for KEY_MAX _bits_. If this is the
main user, why not just change the definition to be in bits?

> > - help fix up the userspace driver regardless
>
> In progress.
> >
> > - a year down the line, maybe breakage will be a non-issue.
>
> Around when 2.6.28 is released, right? ;)

A year down the line would be 2.6.30 or so.

> We do need more keycodes. People are coming wioth more and more. The
> patch following the one in question adds about 10 new kodes for remote
> controls/phones. And we will get more.

Maybe the problem is a bad design that encourages people to just create
new keycodes when they really shouldn't?

Linus