From: Borislav Petkov <[email protected]>
Today, April 1st 2015, marks almost 15 years since the introduction of
the 64-bit extensions to the x86 architecture. And frankly, 15 years was
a graceful period enough for people to move to 64-bit. Therefore, today,
I'm removing 32-bit support from x86 Linux. And it was about friggin'
time...
32-bit code is old, full of nasty hacks and keeps always breaking when
we do our shiny new features for 64-bit. And frankly, no one cares
about 32-bit. If you do, then you're wrong and you need to get with the
program. Go out, take a deep breath, go for a walk and the first thing
you do when you come back is *take* *a* *look* at the goddam calendar.
Time to say goodbye to your old 32-bit sand. Get a 64-bit processor.
Live a little. Come to the real world.
This is a minimal patch which prevents from building a 32-bit kernel
only. Removing of the rest of the crazy ifdeffery and potential cleanups
needs to come later, in nice clean patches. This is especially true for
you, you patch count wankers. Restrain yourself!
Signed-off-by: Borislav Petkov <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Jörg Rödel <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Jeff Mahoney <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Andre Przywara <[email protected]>
Cc: Andreas Herrmann <[email protected]>
Cc: Robert Richter <[email protected]>
Cc: Richard Weinberger <[email protected]>
---
Makefile | 3 ---
arch/x86/Kconfig | 9 ++-------
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index da36a3be7969..0a907dd934b6 100644
--- a/Makefile
+++ b/Makefile
@@ -256,9 +256,6 @@ UTS_MACHINE := $(ARCH)
SRCARCH := $(ARCH)
# Additional ARCH settings for x86
-ifeq ($(ARCH),i386)
- SRCARCH := x86
-endif
ifeq ($(ARCH),x86_64)
SRCARCH := x86
endif
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8db84b0e5bbd..9fed79e3ed39 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1,13 +1,8 @@
-# Select 32 or 64 bit
config 64BIT
- bool "64-bit kernel" if ARCH = "x86"
- default ARCH != "i386"
- ---help---
- Say yes to build a 64-bit kernel - formerly known as x86_64
- Say no to build a 32-bit kernel - formerly known as i386
+ def_bool y
config X86_32
- def_bool y
+ def_bool n
depends on !64BIT
select CLKSRC_I8253
select HAVE_UID16
--
2.3.3
peterz says I forgot to Cc Linus. My bad. Fixed.
On Wed, Apr 01, 2015 at 10:15:58AM +0200, Borislav Petkov wrote:
> From: Borislav Petkov <[email protected]>
>
> Today, April 1st 2015, marks almost 15 years since the introduction of
> the 64-bit extensions to the x86 architecture. And frankly, 15 years was
> a graceful period enough for people to move to 64-bit. Therefore, today,
> I'm removing 32-bit support from x86 Linux. And it was about friggin'
> time...
>
> 32-bit code is old, full of nasty hacks and keeps always breaking when
> we do our shiny new features for 64-bit. And frankly, no one cares
> about 32-bit. If you do, then you're wrong and you need to get with the
> program. Go out, take a deep breath, go for a walk and the first thing
> you do when you come back is *take* *a* *look* at the goddam calendar.
> Time to say goodbye to your old 32-bit sand. Get a 64-bit processor.
> Live a little. Come to the real world.
>
> This is a minimal patch which prevents from building a 32-bit kernel
> only. Removing of the rest of the crazy ifdeffery and potential cleanups
> needs to come later, in nice clean patches. This is especially true for
> you, you patch count wankers. Restrain yourself!
>
> Signed-off-by: Borislav Petkov <[email protected]>
> Cc: H. Peter Anvin <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Tony Luck <[email protected]>
> Cc: Peter Zijlstra <[email protected]>
> Cc: Steven Rostedt <[email protected]>
> Cc: Andy Lutomirski <[email protected]>
> Cc: Matt Fleming <[email protected]>
> Cc: Jörg Rödel <[email protected]>
> Cc: Jiri Kosina <[email protected]>
> Cc: Jeff Mahoney <[email protected]>
> Cc: Michal Hocko <[email protected]>
> Cc: Vlastimil Babka <[email protected]>
> Cc: Andre Przywara <[email protected]>
> Cc: Andreas Herrmann <[email protected]>
> Cc: Robert Richter <[email protected]>
> Cc: Richard Weinberger <[email protected]>
> ---
> Makefile | 3 ---
> arch/x86/Kconfig | 9 ++-------
> 2 files changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index da36a3be7969..0a907dd934b6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -256,9 +256,6 @@ UTS_MACHINE := $(ARCH)
> SRCARCH := $(ARCH)
>
> # Additional ARCH settings for x86
> -ifeq ($(ARCH),i386)
> - SRCARCH := x86
> -endif
> ifeq ($(ARCH),x86_64)
> SRCARCH := x86
> endif
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 8db84b0e5bbd..9fed79e3ed39 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1,13 +1,8 @@
> -# Select 32 or 64 bit
> config 64BIT
> - bool "64-bit kernel" if ARCH = "x86"
> - default ARCH != "i386"
> - ---help---
> - Say yes to build a 64-bit kernel - formerly known as x86_64
> - Say no to build a 32-bit kernel - formerly known as i386
> + def_bool y
>
> config X86_32
> - def_bool y
> + def_bool n
> depends on !64BIT
> select CLKSRC_I8253
> select HAVE_UID16
> --
> 2.3.3
>
>
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
* Borislav Petkov <[email protected]> wrote:
> peterz says I forgot to Cc Linus. My bad. Fixed.
Yeah, although this cleanup really shouldn't be controversial so I'll
merge it up for a v4.0 merge ASAP.
Thanks,
Ingo
(cc'ing Andi)
> On Wed, Apr 01, 2015 at 10:15:58AM +0200, Borislav Petkov wrote:
> > From: Borislav Petkov <[email protected]>
> >
> > Today, April 1st 2015, marks almost 15 years since the introduction of
> > the 64-bit extensions to the x86 architecture. And frankly, 15 years was
> > a graceful period enough for people to move to 64-bit. Therefore, today,
> > I'm removing 32-bit support from x86 Linux. And it was about friggin'
> > time...
No, I vaguely remember booting the first 64 bit cpu (on real hw) for
the 2002-2003 time frame. I need to check my memories on a more exact
date, but you guys from Suse should know better. So 15 years are not
yet over and I really would like to wait at least until then. Another
question is if 64-bit simulators take into account here.
Though, I assume a discussion on this topic will at least take 1-2
years, so it's good to start with it now. Also, I really would like to
finally switch off and retire my K7 which still runs some regression
tests (will need to check the actual used kernel version). It was a
good time, but now I realize it's somehow over. Considering this and
apart from my concerns above:
Acked-by: Robert Richter <[email protected]>
-Robert
On 01.04.15 10:56:00, Robert Richter wrote:
> (cc'ing Andi)
>
> > On Wed, Apr 01, 2015 at 10:15:58AM +0200, Borislav Petkov wrote:
> > > From: Borislav Petkov <[email protected]>
> > >
> > > Today, April 1st 2015, marks almost 15 years since the introduction of
> > > the 64-bit extensions to the x86 architecture. And frankly, 15 years was
> > > a graceful period enough for people to move to 64-bit. Therefore, today,
> > > I'm removing 32-bit support from x86 Linux. And it was about friggin'
> > > time...
>
> No, I vaguely remember booting the first 64 bit cpu (on real hw) for
> the 2002-2003 time frame. I need to check my memories on a more exact
> date, but you guys from Suse should know better. So 15 years are not
Looks like Feb 7 2002, assuming this is genuine:
http://www.theinquirer.net/inquirer/news/1049122/amd-microsoft-hammer-memo-leaked
Not sure about Linux first booting 64 bit.
-Robert
> yet over and I really would like to wait at least until then. Another
> question is if 64-bit simulators take into account here.
>
> Though, I assume a discussion on this topic will at least take 1-2
> years, so it's good to start with it now. Also, I really would like to
> finally switch off and retire my K7 which still runs some regression
> tests (will need to check the actual used kernel version). It was a
> good time, but now I realize it's somehow over. Considering this and
> apart from my concerns above:
>
> Acked-by: Robert Richter <[email protected]>
>
> -Robert
* Robert Richter <[email protected]> wrote:
> [...]
>
> Though, I assume a discussion on this topic will at least take 1-2
> years, so it's good to start with it now. Also, I really would like
> to finally switch off and retire my K7 which still runs some
> regression tests (will need to check the actual used kernel
> version). It was a good time, but now I realize it's somehow over.
> Considering this and apart from my concerns above:
>
> Acked-by: Robert Richter <[email protected]>
Yeah, and phasing out 32-bit support will make it easier to add the
(inevitable) 128-bit support as well, lifting the ~18 exabytes memory
limit. That will allow us to move the 64-bit code into 'bugfix only'
legacy status.
We really don't want to have this unmaintainable mixture of:
128-bit support
64-bit support (legacy mode)
32-bit support (compat mode)
16-bit support (vm86 mode)
8-bit support (UART mode)
... all in the same kernel! We want a cleaner, more maintainable
structure:
128-bit support
64-bit support (compat mode)
... which more closely resembles today's kernel.
Another related change I'd like to make is to drop !SMP support and to
default the kernel build to 4096 CPUs, and to move lower CPU counts to
under CONFIG_EXPERT=y. By the time the commit trickles through to
distros 1000-4000 core phones will be commonplace, so we might as well
start the transition today.
Thanks,
Ingo
> We really don't want to have this unmaintainable mixture of:
>
> 128-bit support
> 64-bit support (legacy mode)
> 32-bit support (compat mode)
> 16-bit support (vm86 mode)
> 8-bit support (UART mode)
>
> ... all in the same kernel!
I think a lot of us working on other free Unixlike OS platforms have
reached a similar conclusion. It's a natural segmentation. The final
commit should include the following helpful table
Bits Free Unixlike OS
---------------------------------
8bit FUZIX
16bit ELKS
32bit NetBSD/FreeBSD
64bit Linux
(For 18 and 36bit consult a specialist.. probably a medical one)
Alan
On Wed, Apr 01, 2015 at 03:41:55PM +0100, One Thousand Gnomes wrote:
>
> I think a lot of us working on other free Unixlike OS platforms have
> reached a similar conclusion. It's a natural segmentation. The final
> commit should include the following helpful table
>
>
> Bits Free Unixlike OS
> ---------------------------------
> 8bit FUZIX
> 16bit ELKS
> 32bit NetBSD/FreeBSD
> 64bit Linux
>
> (For 18 and 36bit consult a specialist.. probably a medical one)
Hey! My father still has a PDP-15/30, complete with core memory, 4
DECtape units, and a high speed punched paper tape reader, all in
a really tiny footprint of 4 full-height 19 inch racks, in his house.
It hasn't been turned on in over a decade, but doesn't deserve a Free
Unixlike OS of its own? :-)
- Ted
> Hey! My father still has a PDP-15/30, complete with core memory, 4
> DECtape units, and a high speed punched paper tape reader, all in
> a really tiny footprint of 4 full-height 19 inch racks, in his house.
> It hasn't been turned on in over a decade, but doesn't deserve a Free
> Unixlike OS of its own? :-)
It would be greener to write a java emulator to run in a browser on a phone (1e4 less power? 1e5??)
Probably run 100x faster too.
-Tony
On Wed, Apr 01, 2015 at 03:46:37PM +0000, Luck, Tony wrote:
> > Hey! My father still has a PDP-15/30, complete with core memory, 4
> > DECtape units, and a high speed punched paper tape reader, all in
> > a really tiny footprint of 4 full-height 19 inch racks, in his house.
> > It hasn't been turned on in over a decade, but doesn't deserve a Free
> > Unixlike OS of its own? :-)
>
> It would be greener to write a java emulator to run in a browser on a phone (1e4 less power? 1e5??)
> Probably run 100x faster too.
I wonder at what point do we say the same thing about ia64 ?
Dave
> Looks like Feb 7 2002, assuming this is genuine:
>
> http://www.theinquirer.net/inquirer/news/1049122/amd-microsoft-hammer-memo-leaked
>
> Not sure about Linux first booting 64 bit.
x86-64 Linux first boot was around the same time.
Also it was running on simulators for a long time before that.
In fact we were mainline when it was only running on
simulators.
-Andi