From owner-freebsd-arch@FreeBSD.ORG Fri Jul 8 17:53:02 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DF1A1065670; Fri, 8 Jul 2011 17:53:02 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id D5DFC8FC0C; Fri, 8 Jul 2011 17:53:01 +0000 (UTC) Received: by yxl31 with SMTP id 31so1102870yxl.13 for ; Fri, 08 Jul 2011 10:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c91TLDtYKcR8ueXQrGZapmd4sSQmN/ZDK8t04WQEAJY=; b=XUtSZYk0ZVyNn8WeUBI4CeNrYQGCEDRNsLLZitn0wpyCA7YtDy591pcvcwR9AXCAVJ tvBwff9dBbDWRfX8sA7LZsr5OHUPBJucgzwCX51wEXWVcYiLT7pOuiQFC4rePED3rQo2 uZmzC7XDvuz8Hrhg0slVohWyP5qIjiseuHBOk= MIME-Version: 1.0 Received: by 10.90.255.18 with SMTP id c18mr2281461agi.31.1310147580828; Fri, 08 Jul 2011 10:53:00 -0700 (PDT) Received: by 10.91.183.18 with HTTP; Fri, 8 Jul 2011 10:53:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jul 2011 10:53:00 -0700 Message-ID: From: Peter Wemm To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Cc: Sergey Kandaurov , freebsd-arch@freebsd.org Subject: Re: [PATCH] Add MAXCPU as a kernel config option and quality discussion on this X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:53:02 -0000 On Fri, Jul 8, 2011 at 8:37 AM, Attilio Rao wrote: > In my case, I think that including opt_maxcpu is a viable panacea, but > in general, after discussing with peter@, probabilly the better idea > would be having a centralized script that does pre-processing before > to start compiling and set with the right values all those constants > (something like genassym.c, but of course with a different purpose). At the risk of fragmenting the thread, I wanted to clarify the goals of what I was talking about last night. What makes me happy is when I can change a value in my config file, and after running 'config FOO; make depend; make', the 6 files affected by the value get recompiled and that's it. That's the point of keeping the dependencies limited. Putting stuff in opt_global.h defeats this. Putting opt_maxcpu.h into a widely included file also defeats this. The genassym/centralized script approach also defeats it. I think the issue you're mainly worried about is correctly detecting when the config override value failed to be pulled in for something that is important. What I suggested earlier will do that and will keep me happy by not adding false dependencies. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell