svn commit: r314669 - head/sys/i386/conf

[Pedro Giffuni]

> Il giorno 05 mar 2017, alle ore 18:24, John Baldwin <jhb at freebsd.org> ha scritto:
> 
> On Saturday, March 04, 2017 08:14:11 PM Pedro Giffuni wrote:
>> 
>> On 3/4/2017 5:51 PM, John Baldwin wrote:
>>> On Saturday, March 04, 2017 03:49:52 PM Pedro Giffuni wrote:
>>>>> Il giorno 04 mar 2017, alle ore 14:43, John Baldwin <jhb at freebsd.org> ha scritto:
>>>>> 
>>>>> On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote:
>>>>>> On 03/04/17 10:32, Slawa Olhovchenkov wrote:
>>>>>>> On Sat, Mar 04, 2017 at 03:04:17PM +0000, Pedro F. Giffuni wrote:
>>>>>>> 
>>>>>>>> Author: pfg
>>>>>>>> Date: Sat Mar  4 15:04:17 2017
>>>>>>>> New Revision: 314669
>>>>>>>> URL: https://svnweb.freebsd.org/changeset/base/314669
>>>>>>>> 
>>>>>>>> Log:
>>>>>>>>  Drop i486 from the default i386 GENERIC kernel configuration.
>>>>>>>> 
>>>>>>>>  80486 production was stopped by Intel on September 2007. Dropping the 486
>>>>>>>>  configuration option from the GENERIC kernel improves performance
>>>>>>>>  slightly.
>>>>>>>> 
>>>>>>>>  Removing I486_CPU is consistent at this time: we don't support any
>>>>>>>>  processor without a FPU and the PC-98 arch, which frequently involved i486
>>>>>>>>  CPUs, is also gone so we don't test such platforms anymore.
>>>>>>> What is realy mean?
>>>>>> This means we don't do work-arounds that would be required for raw 486.
>>>>>> Instead we will use the 586 instructions by default.
>>>>> This doesn't change that.  The kernel already has runtime tests in place
>>>>> for new things on 486 and later via cpuid.
>>>>> 
>>>> Hmm ..then I am wondering if I effectively changed anything?
>>> The only change is a 486 now panics on boot when it used to work fine. :-/
>>> 
>>> Nothing for other CPUs has changed.
>> 
>> Not much has been lost then.
>> FWIW, I have a "Pentium overdrive" somewhere in the basement which could 
>> theoretically boot FreeBSD 12 but last I remember just rebuilding a 
>> kernel was painful and the memory and HD limitations really make it a no-go.
> 
> So I would rather support 486 in GENERIC or not support it at all.  It doesn't
> cost anything for it to be in GENERIC, so if we have it, I think we should ship
> it.  Also, the original justification for this commit of a 4% performance gain
> doesn't seem to have any basis in fact.  The one gain I can think of is
> de-cluttering some things like identcpu.c and initcpu.c which can only happen if
> we remove code entirely, not from removing an option in GENERIC.
> 

OK, that’s reasonable. I will revert the change.

Pedro.