New CPUTYPE default for i386 port

[Bob Bishop]

> On 5 Oct 2019, at 23:50, Ian Lepore <ian at freebsd.org> wrote:
> 
> On Sat, 2019-10-05 at 14:20 -0700, Cy Schubert wrote:
>> 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:
>>>>> 
> [...]
>>>> 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
>>> 
>>> 
>> 
>> 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.)
>> 
>> 
> 
> Only i386 has a 32-bit time_t.  Other 32-bit arches either began life
> with 64-bit time_t or have been switched to it.
> 
> For i386, if its current users (and I am one, for $work) have a choice
> between "As of date X there will be no more i386" and "As of date X we
> switch time_t to 64 bits and you will not be able to run old binaries
> after that" I suspect people would choose the latter.
> 
> — Ian

Obvious casualties of total i386 deprecation would be Soekris 45xx (AMD Elan (i486)) and 55xx (AMD Geode (i586)), we have small numbers of those running recent HEAD. We are only still using them because they are more or less indestructible (especially compared with a lot of the ARM-based offerings). I don’t think we’d complain if i386 support ceased on a reasonable timescale.

--
Bob Bishop
rb at gid.co.uk