From owner-freebsd-arch@FreeBSD.ORG Fri Jan 15 18:59:42 2010 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 3DAAD106568F; Fri, 15 Jan 2010 18:59:42 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 205958FC16; Fri, 15 Jan 2010 18:59:41 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KWA00DXOY2OK690@asmtp029.mac.com>; Fri, 15 Jan 2010 10:59:30 -0800 (PST) From: Marcel Moolenaar In-reply-to: <20100115.110528.849557997928257031.imp@bsdimp.com> Date: Fri, 15 Jan 2010 10:59:11 -0800 Message-id: References: <20100115114822.O63406@delplex.bde.org> <20100115174711.GF1990@FreeBSD.org> <20100115.110528.849557997928257031.imp@bsdimp.com> To: "M. Warner Losh" X-Mailer: Apple Mail (2.1077) Cc: dougb@freebsd.org, svn-src-all@freebsd.org, wkoszek@freebsd.org, src-committers@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, svn-src-head@freebsd.org Subject: Re: INCLUDE_CONFIG_FILE in GENERIC 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, 15 Jan 2010 18:59:42 -0000 On Jan 15, 2010, at 10:05 AM, M. Warner Losh wrote: > : Is this really so hard? > > Yes. Didn't you read the message I posted about why this is hard? No, I didn't. > There would be a ton of lexer and parser work to make this happen, as > well as a lot of work to internal data structures to keep the file as > parsed, rather than as convenient to do config's job. It is a big > pita. PITA != hard. If we're not willing to put in the effort to fix something, I don't think we should call it hard to do. We should call it like it is: non-trivial, involved or significant. Heck, we can even call it a major undertaking. But hard? No, I don't think it's hard at all. > I think the way forward isn't as you suggest. Fine. Just stop trying to classify people as a basis for what behaviour we should implement. It never works... > If > we really make it include everything, then -C can go away, the weird > pseudo thing we have can go away, and we know get everything. And it > is easy to implement... > > Comments? How does this address the "I don't want everything, I just want my CVS keyword" example? How does it handle the delicate balance between space vs. functionality that exists on embedded and/or low-end platforms. An all inclusive implementation seems not to take that into account that well. Sure, you can compress but then you add a runtime overhead to uncompress. In any case: I personally don't use the option so I really should not get involved. If I were to implement something from scratch though, I would treat it as a C file: the config file is the source and you "compile" it into a binary form suitable for inclusion into the kernel and you have compile-time options that control the binary output. No comments will be included in that case and there will be no option for it. But that's just me... -- Marcel Moolenaar xcllnt@mac.com