Date: Tue, 30 May 2023 13:57:17 -0500 From: Mike Karels <mike@karels.net> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Future of 32-bit platforms (including i386) Message-ID: <2FA8A693-13A0-4540-A49B-79B694FFBF1D@karels.net> In-Reply-To: <018790e3-3ede-2397-651a-69cc7567e903@FreeBSD.org> References: <aaa3e005-5f72-f422-56b1-932842379e15@FreeBSD.org> <CANCZdfobbiuihpEZ9sUV_LwvhNpeLP6Y1nxfXUidqCOhiMejYg@mail.gmail.com> <CAFYkXj=AaVnx0Ps0RX-QWSw=4=v=Hf13ASJKvSLKawQyZ8D0QA@mail.gmail.com> <ZHB6ADSfPXv8Yuj9@server.rulingia.com> <CAFYkXj=DLZ24hhKrutLNV03=yBWT-%2B-u7DNDPwhxZH1CEzC0MA@mail.gmail.com> <6dd8a279-1ccf-ea66-9009-3865a7865e1a@selasky.org> <018790e3-3ede-2397-651a-69cc7567e903@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 May 2023, at 12:55, John Baldwin wrote: > On 5/30/23 7:36 AM, Hans Petter Selasky wrote: >> ... >> 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). One advantage of having at least one 32-bit system as part of the build is that it finds mismatched/non-portable use of integer types and format strings. If there is no real 32-bit platform worth updating, maybe we could include a “null” 32-bit port, e.g. one without machine-dependent code other than headers? It could be based on i386 or armv7, but obviously would not include a full kernel. It could potentially include stubs to allow the kernel to link, but just generating object files for the MI parts would be valuable. Does anyone have any idea how much work this might be? If we have the ability to build 32-bit user-level binaries with -m32, the kernel or kernel objects would be the main addition. Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2FA8A693-13A0-4540-A49B-79B694FFBF1D>