Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jul 2013 19:56:03 -0700
From:      Adrian Chadd <adrian@freebsd.org>
To:        Juli Mallett <juli@clockworksquid.com>
Cc:        Warner Losh <imp@freebsd.org>, "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org>
Subject:   Re: Can we undo the octeon hack?
Message-ID:  <CAJ-VmoniT-2cX9y%2BcfQJQ7OwMnbvjB1gTHym_LT=ngy8AnuN2g@mail.gmail.com>
In-Reply-To: <CACVs6=9mjoB7LQ4OkvT7CJ8b0cG_G9o9XJsAauqxUYwo7MFpkQ@mail.gmail.com>
References:  <CAJ-VmonJg2BhBdckFb1O79ZnWrXKZhT%2Bku9SjuswLui6iZC1Ow@mail.gmail.com> <6401792509903023722@unknownmsgid> <F0B68A50-B5BF-426E-874C-1EFC03CAEAEB@bsdimp.com> <CACVs6=_Ss_C0v_eHFzOsM1QKi43EU4j3SUmOTsC=XmhMFPqeAw@mail.gmail.com> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> <CACVs6=9mjoB7LQ4OkvT7CJ8b0cG_G9o9XJsAauqxUYwo7MFpkQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
.... ok, so, what's the game plan? :)



-adrian

On 21 July 2013 18:47, Juli Mallett <juli@clockworksquid.com> wrote:
> Do you think we should gate moving this singular hack to the Octeon
> config file on breaking out a bunch of std.foo files now? :)  I was
> just saying that if you're advocating doing that work, we should do
> some more generalized stuff, too.  Like, std.pcidriversandwhatnot
> should be machine-independent and would reduce a lot of maintenance
> between architectures, that kind of thing.  I don't think any of it
> should gate moving INLINE_CFLAG_SOMETHING_FOO_WHATEVER_BISCUIT_* into
> the Octeon kernel config and out of sys/conf.
>
> On Sun, Jul 21, 2013 at 6:34 PM, Warner Losh <imp@bsdimp.com> wrote:
>> I would too, but let's not gate a solution to this problem on that.
>>
>> Warner
>>
>> On Jul 21, 2013, at 3:29 PM, Juli Mallett wrote:
>>
>>> I would really like a std.pci or something, too, so we don't have to
>>> enumerate all the PCI devices in every config.
>>>
>>> On Sun, Jul 21, 2013 at 1:51 PM, Warner Losh <imp@bsdimp.com> wrote:
>>>> These should really be in the std.foo files for each specific subport. That way atheros could have one set, and octeon could have another.
>>>>
>>>> I do know that we don't do the std.foo thing for the atheros config files, but we really should start, and this would be a good place to start...
>>>>
>>>> Warner
>>>>
>>>> On Jul 21, 2013, at 12:54 PM, Juli Mallett wrote:
>>>>
>>>>> Making it possible to override each value would be ideal but
>>>>> cumbersome.  If you want to do that, by all means do!
>>>>>
>>>>> Thanks,
>>>>> Juli.
>>>>>
>>>>> On 2013-07-21, at 11:44, Adrian Chadd <adrian@freebsd.org> wrote:
>>>>>
>>>>>> Hi Juli/Warner,
>>>>>>
>>>>>> Is it possible to undo this particular hack, and allow these values to
>>>>>> be overridden in the kernel config files?
>>>>>>
>>>>>> from kern.pre.mk
>>>>>>
>>>>>> CFLAGS= ${COPTFLAGS} ${C_DIALECT} ${DEBUG} ${CWARNFLAGS}
>>>>>> CFLAGS+= ${INCLUDES} -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
>>>>>> opt_global.h
>>>>>> .if ${COMPILER_TYPE} != "clang"
>>>>>> CFLAGS+= -fno-common -finline-limit=${INLINE_LIMIT}
>>>>>> .if ${MACHINE_CPUARCH} != "mips"
>>>>>> CFLAGS+= --param inline-unit-growth=100
>>>>>> CFLAGS+= --param large-function-growth=1000
>>>>>> .else
>>>>>> # XXX Actually a gross hack just for Octeon because of the Simple Executive.
>>>>>> CFLAGS+= --param inline-unit-growth=10000
>>>>>> CFLAGS+= --param large-function-growth=100000
>>>>>> CFLAGS+= --param max-inline-insns-single=10000
>>>>>> .endif
>>>>>> .endif
>>>>>>
>>>>>> I'd like to be able to experiment with different inline settings in
>>>>>> order to try and squeeze kernels down to be smaller.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> -adrian
>>>>
>>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmoniT-2cX9y%2BcfQJQ7OwMnbvjB1gTHym_LT=ngy8AnuN2g>