Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
"Theodore Y. Ts'o" writes:
> On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton wrote:
>> so i hope that list gives a bit more context as to how serious the
>> consequences of dropping 32 bit support really is.
>
> I very much doubt we are any where near "dropping 32-bit support".
> There's a lot of "all or nothing thinking" in your argumentation
> style.
The topic of this very thread is how to avoid dropping support for 32bit
architectures. So people clearly want to continue supporting it.
> As Sam has said multiple times, what's much more likely is that the
> set of packages that can't be built on native packages on 32-bit
> platforms will grow over time. The question is when will that
> actually *matter*? There are many of these packages which no one
> would want to run on a 32-bit platform, especially if we're focusing
> on the embedded use case.
It might matter pretty soon: for generic-purpose systems one almost
always want to be able to use a web browser; even various embedded
systems do. However web browsers are one of the most heavy packages to
build.
> At least initially, the simplest way of dealing with the problem is
> that maintainers will simply not build their package on 32-bit
> platforms.
I don't think we want this to happen if we want to continue supporting
32bit systems. But using a 64bit toolchain in an otherwise 32bit
userland as the thread suggests we now really should start looking at
will avoid this.
It will probably take a few more years until we have to worry about
being able to run browsers in 32bit... But I would hope that most
people understand that using 32bit for new generic-purpose systems is
not future-proof (and hasn't been for a while); even phones have started
to move to 64bit systems a while ago.
Ansgar
Reply to: