Date: Sat, 5 Oct 2019 20:22:58 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Warner Losh <imp@bsdimp.com> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, freebsd-arch@freebsd.org Subject: Re: New CPUTYPE default for i386 port Message-ID: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> In-Reply-To: <CANCZdfqL2LD_Yu49XMid-G21w-HKSDA4yW4Wi_uEW37rAG9E2Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sat, Oct 5, 2019, 11:03 AM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> 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? > > > > Please provide some type of eol statement in the next release cycle release > > notes that base and packages are no longer usable on the class of i386 > > lower > > than i686, with the above rationale and work around. > > > > Sure. Of course. > > >From the above it does sound as if you plan to MFC this back as far as 11? > > > > No plans to MFC. Ok, so this is an issue at 13 and later, so people could update legacy stuff into stable/12 in the future, thats lots of head room looking forward. > > > What is the error condition one sees if you try to boot release media > > built i686 on a i386/i486 system? It needs to be something sinceable > > and preferable some direction to work around, not just some random illegal > > instruction panic, PLEASE! > > > > We should remove 486 and 586 CPU support from GENERIC and then the kernel > would say the CPU was unsupported. But only if there were no illegal > instructions. That is my concern, that we are going to end up with some crazy fault or panic that is cryptic and leaves the user with little clue as to what went wrong. > However, GENERIC already requires 128MB or 256MB or more to > boot, which is beyond what 486 and 586 could have on them so it may be a > moot point. 586 == Pentium I, almost all, if not all chipsets in the family support 128MB, and many supported 192 to 512MB. > Other than those 2 issues and 1 question I have no objection to doing this. > > Regards, > > -- > > Rod Grimes > > rgrimes@freebsd.org > > -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201910060322.x963Mwo1065732>