On Thu, Jul 31, 2008 at 01:16:52PM -0700, Linus Torvalds wrote:

On Thu, 31 Jul 2008, Dmitry Torokhov wrote:

quoted

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. 

OK.

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.

Here we don't extend the interface though.

quoted

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?

Because X proper, HAL, DirectFB and many other users got it right and
changing it to mean bits would break _them_.

quoted

quoted

 - help fix up the userspace driver regardless

In progress.

quoted

 - 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.

I guess that means that we have to have that patch that spits warning
and reduces size of returned data of it detects 01ff buffer size.
Still, its uuuuugllllyyy.

quoted

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? 

That is bigger topic. HID spec has much more events for differect
things though. FOr example the new key definitions for the phones - we
want to have a separate # key and not try to combine "shift" and "3"
and also have separate numeric keys taht don't depend on register and
NumLock state. If we don't have such keycodes we have trouble with
some european users that have numbers in upper register...

-- 
Dmitry