Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Oct 2019 12:19:41 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Shawn Webb <shawn.webb@hardenedbsd.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: New CPUTYPE default for i386 port
Message-ID:  <CANCZdfo6=r7BaGA8qKYSR9ba=azzxD%2ByDkN4aO87Oj1Qr9TKmA@mail.gmail.com>
In-Reply-To: <20191005173411.l6gs3kszs7zcgfey@mutt-hbsd>
References:  <CANCZdfoFPsjyuCTfm0dQhz%2BsgVHLEvMA8-E3-Yhciz67qdoKvw@mail.gmail.com> <20191005173411.l6gs3kszs7zcgfey@mutt-hbsd>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 5, 2019, 11:34 AM Shawn Webb <shawn.webb@hardenedbsd.org> wrote:

> On Sat, Oct 05, 2019 at 09:28:53AM -0600, Warner Losh wrote:
> > For a variety of reasons,  the time has come to change the default code
> > generation arch from i486 to i686 on our i386 port. No actual code
> removal
> > is planned as part of this effort. Only the default is doing changed for
> > clang.
> >
> > The practical upshot of this for our i386 users will be zero for almost
> > everybody. For the tiny sliver of people planning to deploy FreeBSD on a
> > i486 or i586 core, a simple addition of CPUTYPE=xxxx to /etc/make.conf is
> > all that is needed for the src side of things. They will need to setup
> > their own poudriere instance and create their own pkg repo to build
> > whatever packages are required for their deployment.
> >
> > It's my belief that even in the trailing edge long tail embedded
> deployment
> > segment of our user base this will cause no issues. All deployments there
> > I'm aware of have moved of i486 class CPUs and the one 586 class core
> > deployment I know of has no plans to update that to FreeBSD 11, let alone
> > newer.
> >
> > There are a number of advantages to doing this which have been
> articulated
> > at length in other discussions. Briefly we get better code generation for
> > CPUs people use and we avoid some test failures in llvm 9.0 because i486
> > doesn't have 64-bot atomics.
> >
> > Comments?
>
> Full disclosure: I personally don't care about 32-bit architectures.
> Feel free to ignore me based on that. ;-)
>
> I'm curious about the possibilities regarding 64-bit time_t on 32-bit
> Intel systems.
>

Beyond the scope of this discussion. However, feel free to start a thread
on this. It's quite difficult to switch if you want binary compat. It would
affect system calls on the upgrade path and is among the hardest types to
change if you have any kind of legacy to support...

Warner


Thanks,
>
> --
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
>
> Tor-ified Signal:    +1 443-546-8752
> Tor+XMPP+OTR:        lattera@is.a.hacker.sx
> GPG Key ID:          0xFF2E67A277F8E1FA
> GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo6=r7BaGA8qKYSR9ba=azzxD%2ByDkN4aO87Oj1Qr9TKmA>