Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

On 2/28/19 10:32 AM, Steve Kargl wrote:
> On Thu, Feb 28, 2019 at 09:09:38AM -0800, John Baldwin wrote:
>> You can do all your tests directly on amd64 by just adding
>> "-m32" to compile i386 binaries against the libraries in /usr/lib32
>> and you will generate the same i386 binaries as if you were building
>> on an i386 system.  If you are a bit more paranoid, you can install
>> an i386 world and chroot into it and use that to test i386.  I do this
>> myself (-m32) for testing i386 things.  I also run i386 VMs under
>> bhyve on amd64 hosts.  I'm not sure your laptop's CPU can run i386
>> VMs though, and you don't need a VM to test userland-only changes
>> (I'm usually trying to test kernel changes).
> 
> Interesting.  Did not know I could use -m32 with any reliability.
> Setting up my testing environment may be a challenge as I use
> mpfr/gmp, so would need -m32 aware versions of those libraries.
> I normally install whatever the port collection offers for mpfr/gmp.
> I suppose I would need to install those independently to get
> multilib support.  I would also need to compile 2 versions of my
> testing framework (ie., additional support library).

-m32 didn't used to work in early amd64 (like 6.x or maybe 7.x), but it has worked
reliably for several branches now.  That said, if you want to use i386 packages, I
think a chroot is probably a safer route as in the chroot you can use pkg to install
i386 packages just as if it was an i386 machine.

> The BIOS does have a enable/disable button for virtualization.
> During the great drm-legacy-kmod event of the last month, enabling
> virtualization locks up a i386 FreeBSD kernel very quickly.
> Perhaps, virtualization works under amd64.  Guess I'll burn
> an image onto a memstick an d give it a whirl.

bhyve is definitely amd64-only.  We don't have any support for bhyve on i386
kernels and likely never will.  However, if an i386 chroot works, it's probably
faster than an i386 VM anyway.

>> However, an amd64 kernel is going to be a more stable, better
>> supported kernel for running i386 binaries than an i386 kernel
>> at this point, and that will become even more true in the future.
> 
> This is interesting as well.  Does this mean that amd64 is now 
> the only tier 1 platform and all other architectures are after
> thoughts?

i386 is still marked as tier 1.  However, it's becoming increasingly harder to
maintain that level of support for the kernel.  core_at_ is currently exploring
some ideas about how to make our tiering for i386 more closely reflect what we
as a project are able to provide.  Originally we were considering a proposal to
demote all of i386 to tier 2, but after some initial conversations we think a
better model is to keep the i386 user ABI as tier 1 and only demote the i386
kernel.  However, we still need to think about what that looks like and update
our tiering language to reflect what that looks like.  I think the short version
is that we might no longer guarantee i386-specific fixes for kernel SAs, but
there are probably additional wrinkles that will arise as that is fleshed out
further.

-- 
John Baldwin