Message-ID: <20080731162158.ZZRA012@mailhub.coreip.homeip.net>
Date:	Thu, 31 Jul 2008 16:28:49 -0400
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org
Subject: Re: linux-next: Tree for July 30

On Thu, Jul 31, 2008 at 01:16:52PM -0700, Linus Torvalds wrote:
> 
> 
> 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. 

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

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

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.

> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists