Date: Fri, 15 Jan 2010 10:59:11 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: dougb@freebsd.org, svn-src-all@freebsd.org, wkoszek@freebsd.org, src-committers@freebsd.org, rwatson@freebsd.org, brde@optusnet.com.au, freebsd-arch@freebsd.org, svn-src-head@freebsd.org Subject: Re: INCLUDE_CONFIG_FILE in GENERIC Message-ID: <D7A4BDAE-9CF6-45B3-8574-5E7DE89E2FCE@mac.com> In-Reply-To: <20100115.110528.849557997928257031.imp@bsdimp.com> References: <20100115114822.O63406@delplex.bde.org> <20100115174711.GF1990@FreeBSD.org> <FE2858BE-2302-4980-BE73-32885AFBC7C2@mac.com> <20100115.110528.849557997928257031.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D7A4BDAE-9CF6-45B3-8574-5E7DE89E2FCE>