From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 02:56:05 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E67EAB68; Mon, 22 Jul 2013 02:56:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 513341DD6; Mon, 22 Jul 2013 02:56:05 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so1374387wib.8 for ; Sun, 21 Jul 2013 19:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=30mazOPZxmBWxytDBm1niTtfnPsUoCWvOOgl3m97lYI=; b=AXNlExSSKx9Reg776vZik4/H/Q5dp9urMJ2uHoFSavbr1uDN6JZbKixVLTQMNEIeMN WBGv80Y7GbgtUAhFDnBSg6yXDufsHBZPCDW83fT9lEmmmG9fJ8M6r/PjiiwoeR/hh6Y5 gg7sGh2ghy22mPO14qe7pq7jnQSBhsnKZN6ucJpKUGX2nRi/GcTqn0zzAkzGejQuiAhf fsIXX5sBCl3iuqpAjUCrdSI8qp3Wm4Ak2+bNf8TnE4xMhiAdofuqnu2NzaQH4FmAx1zZ pEAxJ3SIVy/zEgGegUxkgWquMlJJtRIxNO7ODbwnk4/xRu2f5NZUkIr9GxhDjBakBk44 lQ6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=30mazOPZxmBWxytDBm1niTtfnPsUoCWvOOgl3m97lYI=; b=bshjw4+K+Doyaf+z70VDRMrVOyUYEvbJ84BYQzX8j40EZihGbgpzucjAHbKiVlIizP s5tW6G7n58tGanOPJ7m4lYZ/RXaZf0vftPoCfmAj5Mu5Gyx5nQTADR4/8I4f+kNrznT9 TVJ5oZcUMQDS8GlZDrAEX+0EF4ThFwU5x3VxmhciaN60mAHOGhWu/Q+QBZNVrappQZMt R+jJiyfJaZj7WjC+6Co1Csyw5B4n7sM6H/72R/Js/PhUjTWja2G3A14wWtT2CoTmfyQP 1I77A+MLKvb3WYDCEhlQvP8w8CHA4WugzCVUQ1/szYS8lEmJKBedvy3ae/Cay1EIfy5M THLA== MIME-Version: 1.0 X-Received: by 10.180.11.6 with SMTP id m6mr4306279wib.0.1374461763646; Sun, 21 Jul 2013 19:56:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 21 Jul 2013 19:56:03 -0700 (PDT) In-Reply-To: References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> Date: Sun, 21 Jul 2013 19:56:03 -0700 X-Google-Sender-Auth: K4h3VUETsyQGqiM8sG0ZD9m7sps Message-ID: Subject: Re: Can we undo the octeon hack? From: Adrian Chadd To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 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 02:56:06 -0000 .... ok, so, what's the game plan? :) -adrian On 21 July 2013 18:47, Juli Mallett 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 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 >>>> >>