From owner-freebsd-arch@FreeBSD.ORG Fri Jan 15 19:54:18 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 A567810656FD; Fri, 15 Jan 2010 19:54:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 52E528FC36; Fri, 15 Jan 2010 19:54:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0FJlPCH035384; Fri, 15 Jan 2010 12:47:25 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 15 Jan 2010 12:48:09 -0700 (MST) Message-Id: <20100115.124809.21010533849792633.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <20100115.110528.849557997928257031.imp@bsdimp.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 19:54:18 -0000 In message: Marcel Moolenaar writes: : : 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. Agreed. But having retrofitted grammars in the past, coupled with the fact that config doesn't create a proper parse tree means we'd be rewriting huge portions of config, almost a complete rewrite from scratch, I'd say, would be necessary. And then you've sunk a huge amount of time into solving a tiny problem. Rewriting config should produce more benefits than just this one problem. That's why I called it hard. : > 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... Actually, engineering is all about identifying classes of users, and showing that solutions map well onto those classes of users. In showing which classes of users the solutions works well for, we can also find holes in the current setup. : > 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. I don't understand the "I just want my CVS keywords expanded" example. I think that's an orthogonal problem entirely (and maybe a small bug-fix to config to include an ident keyword if people really want the config file saved). The CVS keywords for the rest of the kernel are controlled by sys/cdefs, which creates .ident lines which the toolchain is responsible for keeping or ditching. Embedded platforms wouldn't embed the whole config file at all, so I don't see what we do for platforms that aren't resource sensitive would matter here. But all the includes is only 14k on amd64 and i386 (our biggest config file platforms). These particular config files compress down to about 6k. Embedded config files tend to be even smaller, and would likely compress down to about 1.5k-2k (AR71XX is 1.3k without the extra included files). Since the kernel is itself compressed, we wouldn't have to worry too much about it. So even in embedded, the resources consumed are small. : 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... That's basically what's implemented to day: we're but a whisper away from a pure binary for (no -C)... Warner