New CPUTYPE default for i386 port

[Cy Schubert]

On October 5, 2019 11:19:41 AM PDT, Warner Losh <imp at bsdimp.com> wrote:
>On Sat, Oct 5, 2019, 11:34 AM Shawn Webb <shawn.webb at 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 at is.a.hacker.sx
>> GPG Key ID:          0xFF2E67A277F8E1FA
>> GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23
>0FB2
>>
>_______________________________________________
>freebsd-arch at freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-arch
>To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"

This is one of the two reasons I believe we should deprecate 32-bit. Even supporting 32-bit compatibility long term is unsustainable. It is not worth the effort.

Putting a stake in the ground to say we no longer support 32-bit after 2038 would be desirable. (Sooner the better though.)


-- 
Pardon the typos and autocorrect, small keyboard in use. 
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: https://www.FreeBSD.org

The need of the many outweighs the greed of the few.

Sent from my Android device with K-9 Mail. Please excuse my brevity.