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-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
