On 2/28/19 11:24 AM, Cy Schubert wrote: > On February 28, 2019 11:21:24 AM PST, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote: >> On Thu, Feb 28, 2019 at 11:14:51AM -0800, Cy Schubert wrote: >>> On February 28, 2019 11:06:46 AM PST, Conrad Meyer <cem_at_freebsd.org> >> wrote: >>>> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl >>>> <sgk_at_troutmask.apl.washington.edu> wrote: >>>>> This is interesting as well. Does this mean that amd64 is now >>>>> the only tier 1 platform and all other architectures are after >>>>> thoughts? >>>> >>>> This has been the de facto truth for years. i386 is mostly only >>>> supported by virtue of sharing code with amd64. There are efforts >> to >>>> promote arm64 to Tier 1, but it isn't there yet. Power8+ might be >>>> another good alternative Tier 1 candidate eventually. None have >>>> anything like the developer popularity that amd64 enjoys. >>>> >>> >>> We deprecated and removed support for 386 and 486 processors. We >> should consider removing support for low end Pentium as well. I'm >> specifically thinking of removing the workarounds like F00F. Are there >> any processors that are still vulnerable to this? >>> >> >> Ahem, sys/i386/conf/GENERIC contains "cpu I486_CPU". >> Is that a typo? > > I stand corrected. We should remove that. No, it doesn't need removing per my other mail. While there is some cruft in a few files for older CPUs (mostly just initcpu.c and identcpu.c) it is quite small and in code that doesn't change. To effect any type of substantial "win" in reducing code complexity for i386, you'd have to do something like require PAE (so that the kernel could assume PAE instead of a bunch of runtime checks as it does now). That would also give you working 64-bit atomics on i386. However, removing I486_CPU alone doesn't buy you anything. -- John BaldwinReceived on Fri Mar 01 2019 - 00:04:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC