Hi all,
we plan to remove 31 bit kernel support of the s390 architecture in the
Linux kernel sources.
The reason for this is quite simple: the current 31 bit kernel was broken
for nearly a year before somebody noticed.
Keeping the 31 bit kernel support adds extra maintenance and development
effort which we do not want to spend anymore, especially since the effort
seems to be quite pointless, since nobody uses (and tests) the 31 bit
kernel.
Please note, that we will not remove the 31 bit compatibility layer which
allows to run 31 bit applications with a 64 bit kernel. It is also
possible to run a complete 31 bit user space distribution with a 64 bit
kernel.
After the removal of the 31 bit kernel support it is not possible to run
new Linux kernels on old 31 bit only machines. The only supported 31 bit
only machines were the G6 and Multiprise 3000 introduced in 1999. However
after nearly 15 years it seems reasonable to remove support for these old
machines.
We want to remove s390 31 bit kernel support with Linux kernel 3.16.
Thanks,
Heiko
12.02.2014 13:29, Heiko Carstens wrote:
> We want to remove s390 31 bit kernel support with Linux kernel 3.16.
Maybe you can send a patch for Documentation/feature-removal-schedule.txt
about this now?
Thanks,
/mjt
On Thu, Feb 13, 2014 at 11:45 AM, Michael Tokarev <[email protected]> wrote:
> 12.02.2014 13:29, Heiko Carstens wrote:
>> We want to remove s390 31 bit kernel support with Linux kernel 3.16.
>
> Maybe you can send a patch for Documentation/feature-removal-schedule.txt
> about this now?
This file is gone.
commit 9c0ece069b32e8e122aea71aa47181c10eb85ba7
Author: Linus Torvalds <[email protected]>
Date: Mon Oct 1 15:21:43 2012 -0700
Get rid of Documentation/feature-removal.txt
This file has turned out to be a pure write-only file that causes merge
conflicts and has no actual redeeming features.
There is never any reason to add stuff to this idiotic file. Either
something isn't getting used, and you should just remove it, or there is
no excuse for removing it in the first place. Just stop the idiocy.
It has also been the excuse for just plain bad behavior ("Hey, I don't
like xyz, so let's mark it for removal" followed by "Hey, look, it been
in feature-removal.txt for six months now, so we should remove it").
The recent bogus setitimer() ABI change request was just the most recent
example of pointless and incorrect mental masturbation involving this
file, and I'm tired of the silly and pointless conflicts in the file.
This removal was discussed during the recent kernel summit, and while
Steven Rostedt suggested we should just enter the file itself in the
feature-removal schedule (to see if anybody who edits the file actually
looks at it), that's cute but non-productive.
Signed-off-by: Linus Torvalds <[email protected]>
--
Thanks,
//richard