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