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

On 5/30/23 7:36 AM, Hans Petter Selasky wrote:
> 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?

Folks are more than welcome to use bits of FreeBSD in their own codebases,
but FreeBSD is not obligated to maintain those bits in other codebases.
The healthy relationship there is for those consumers to engage with their
upstream (FreeBSD).

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

CHERI is not full 128-bit integers (e.g. long and addresses are still
64-bits), so it's not quite as large a gap as 32 vs 64 (though is close).
  
> 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.

MIPS patents are expired and we removed that, too.  The code is also not
going away, but the question is what is our consensus as a project on where
we want to focus our efforts.

-- 
John Baldwin