From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 01:54:06 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A692C1A for ; Mon, 22 Jul 2013 01:54:06 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 956AD1C6B for ; Mon, 22 Jul 2013 01:54:05 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id x10so4868586lbi.19 for ; Sun, 21 Jul 2013 18:53:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ELMx0uZmqEwNoxarW9IlpVRLkCUgTli1YlSoHwy8AIc=; b=UHokSKX+K4eL/aD4qP4aAvA+VnB546z1aVSN6pU395NvBGVUfG+xNIePxVADjYD6m0 +f8kfpLK0TIGPuinNMKoV3tf9BfqMOX2R7NetjmIox0vOCMX9NnFKI+YHFJDfo4mVHbx 4B6Ii3JrHAjnUyMgwHXpo9E14GV1Xz05ZqFLGOXDlKACSPK6N22b1I58ORCXV7toGRn4 3VGJFx2oIDpg8bSod8K1ZWu0qgtZOv2mPWUnNjmaHM/2UfNMpk8/e22c4DCXVA5WzgxY ZKx8I5m6LGiNn0aGJQkrR/4XEyOo+x9naPJm5EtxP4BMN+hQpWgKcYonokZVwNRyovLq 50Hw== X-Received: by 10.112.97.132 with SMTP id ea4mr11114546lbb.80.1374457662055; Sun, 21 Jul 2013 18:47:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.231 with HTTP; Sun, 21 Jul 2013 18:47:22 -0700 (PDT) In-Reply-To: <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> From: Juli Mallett Date: Sun, 21 Jul 2013 18:47:22 -0700 Message-ID: Subject: Re: Can we undo the octeon hack? To: Warner Losh Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm185fDCK5gbuG0qhLRcVoLAANPElmAjLav5xMyW1yawByd55KpDR/XxLH+1Gj0u7DmFywZ Cc: Warner Losh , "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 01:54:06 -0000 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 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 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 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 >>> >