linux-kernel - Re: linux-next: Tree for July 30

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Jul 2008 13:16:52 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
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, 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
--
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/