Re: Future of 32-bit platforms (including i386)

On 5/26/23 17:31, Tomek CEDRO wrote:
> Thanks Peter.. I know 64-bit is now easier to maintain both in
> software and hardware domain.. I just don't like "Enforced Changes
> Ideologies" so things that worked well needs to be "just deleted and
> replaced".. in most cases this is what destroys our current world..
> its like history rewrite.. maybe marking code as "obsolete" /
> "unsupported" / "abandoned" just for anyone ever wanting to play with
> the code ever again rather than removing the code and leaving nothing
> for the future.. I don't know what are the plans but I think code for
> porting to other platforms should be preserved for various reasons
> even when obsoleted it will be solid source of knowledge 😄

Hi,

I want to add, there are consumers of FreeBSD kernel code, like RTEMS 
and QNX. If someone wants to maintain for example the Network stack for 
a 32-bit platform outside of FreeBSD, how is FreeBSD thinking about 
that? What is the plan there?

Instead of 128/64/32 -bit support it will be 128/64 -bit support 
(thinking about CheriBSD)?

If 32-bit CPU and platform technology patents are about to expire, then 
keeping 32-bit support around could be a scoop for FreeBSD, even though 
32-bit PC platforms are a patchwork of technologies, going from ISA, PnP 
to PCI and USB.

Citing Warner Losh:

 > contains Intel's plans for the future. They have removed support for 
booting 16/32-bit and non-UEFI from their firmware as of 2020...

And it is also well known how secure boot works, and allows Intel to 
control who can use their hardware components or not. I would not be 
surprised at all, if in the future, you would have to pay serious money 
to boot FreeBSD on desktop computers. Apple has already been doing this 
for many years.

Given secure booting is not defined for 32-bit platforms, is this a 
strong argument to keep 32-bit support around?

Personally I would see it as a big step backwards to boot up Windows or 
Apple first, then run VirtualBox or VMware, and then login to FreeBSD. 
Not only would it require you to constantly pull system updates for two 
systems, but it will totally screw performance.

--HPS