From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 19:40:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 19:39:57 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:49359 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Thu, 27 Dec 2001 19:39:44 -0500 Date: Thu, 27 Dec 2001 19:24:34 -0500 Message-Id: <200112280024.fBS0OYH26337@snark.thyrsus.com> From: "Eric S. Raymond" To: Linus Torvalds , Marcelo Tosatti Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: State of the new config & build system Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Linus (and Marcelo): I understand that right at the moment you have higher priorities than merging in the new build system. Keith Owens and I agree with those priorities, so please consider the following to be information rather than pressure for action. Keith's kbuild-2.5 and my CML2 both appear to be shaking down quite nicely. In the last eight weeks the level of beta testing we're getting from lkml regulars has risen dramatically, as has the amount of work being put in on the codebases by people other than Keith and myself (just last night I checked in an entire new X-based front end contributed by a hacker from Korea). Despite the increased attention, the criticality level of incoming bug reports has held steady or decreased, to the point that we're basically both just doing normal maintainance and polishing the chrome now. I haven't seen a really serious bug in CML2 since I resumed active work on it in early November, and Keith's stuff is stable enough that he's now adding features like kernel-image type selection that were obviously way down his to-do list. Just as importantly, the kernel development community now seems to be actively preparing for the build-system cutover, as opposed to just passively waiting for it. Some are doing their cutover in *advance* of the main tree; the kinds of kbuild bug reports I see on the list indicate that Keith's kbuild is already in production use, and in the last week I've gotten requests from SGI's XFS group and the ELKS project for help with switching to CML2. In sum, we're ready now -- but that's been true since at latest early November. What's new in the last couple weeks is that the developer community appears to be coming up to speed on our technology effectively enough to be ready as well. We can help plan and execute the cutover any time you're ready. -- Eric S. Raymond When all government ...in little as in great things... shall be drawn to Washington as the center of all power; it will render powerless the checks provided of one government on another, and will become as venal and oppressive as the government from which we separated." -- Thomas Jefferson, 1821 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 19:55:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 19:55:00 -0500 Received: from ns.suse.de ([213.95.15.193]:10253 "HELO Cantor.suse.de") by vger.kernel.org with SMTP id ; Thu, 27 Dec 2001 19:54:45 -0500 Date: Fri, 28 Dec 2001 01:54:42 +0100 (CET) From: Dave Jones To: "Eric S. Raymond" Cc: Linus Torvalds , Marcelo Tosatti , , Subject: Re: State of the new config & build system In-Reply-To: <200112280024.fBS0OYH26337@snark.thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Dec 2001, Eric S. Raymond wrote: > ..., and Keith's stuff is stable > enough that he's now adding features like kernel-image type selection > that were obviously way down his to-do list. How far down the list was "make it not take twice as long to build the kernel as kbuild 2.4" ? Keith mentioned O(n^2) effects due to each compile operation needing to reload the dependancies etc. Given how early your both pushing to get these into the tree(s), and given how many kernels are going to be built between now and 2.6.0, slowing down development for _every_ kernel developer doesn't strike me as a bright move. Maybe keep them both in the tree until this issue is worked out ? That way those who want to play with kbuild can do so, and those who build a few dozen kernels a day don't have to twiddle thumbs. Don't get me wrong, I'm not knocking CML2 or kbuild2.5, I'm just interested in some of timescale for getting wrinkles like this out. Dave. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:13:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:13:01 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:56783 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Thu, 27 Dec 2001 20:12:40 -0500 Date: Thu, 27 Dec 2001 19:57:38 -0500 From: "Eric S. Raymond" To: Dave Jones Cc: "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011227195738.A26889@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <200112280024.fBS0OYH26337@snark.thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from davej@suse.de on Fri, Dec 28, 2001 at 01:54:42AM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Dave Jones : > Maybe keep them both in the > tree until this issue is worked out ? That way those who want to > play with kbuild can do so, and those who build a few dozen > kernels a day don't have to twiddle thumbs. That is such an unutterably horrible concept that the very tentacles of Cthulhu himself must twitch in dread at the thought. The last thing anyone sane wants to do is have to maintain two parallel build systems at the same time. -- Eric S. Raymond You know why there's a Second Amendment? In case the government fails to follow the first one. -- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:16:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:16:01 -0500 Received: from bitmover.com ([192.132.92.2]:49055 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Thu, 27 Dec 2001 20:15:52 -0500 Date: Thu, 27 Dec 2001 17:15:45 -0800 From: Larry McVoy To: "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011227171545.T25698@work.bitmover.com> Mail-Followup-To: "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <200112280024.fBS0OYH26337@snark.thyrsus.com> <20011227195738.A26889@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20011227195738.A26889@thyrsus.com>; from esr@thyrsus.com on Thu, Dec 27, 2001 at 07:57:38PM -0500 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 27, 2001 at 07:57:38PM -0500, Eric S. Raymond wrote: > Dave Jones : > > Maybe keep them both in the > > tree until this issue is worked out ? That way those who want to > > play with kbuild can do so, and those who build a few dozen > > kernels a day don't have to twiddle thumbs. > > That is such an unutterably horrible concept that the very tentacles > of Cthulhu himself must twitch in dread at the thought. The last thing > anyone sane wants to do is have to maintain two parallel build systems > at the same time. Then it does seem reasonable to ask that the new one is at least as fast as the old one. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:22:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:22:21 -0500 Received: from ns.suse.de ([213.95.15.193]:19470 "HELO Cantor.suse.de") by vger.kernel.org with SMTP id ; Thu, 27 Dec 2001 20:22:02 -0500 Date: Fri, 28 Dec 2001 02:22:01 +0100 (CET) From: Dave Jones To: "Eric S. Raymond" Cc: Linus Torvalds , Marcelo Tosatti , Linux Kernel Mailing List , Subject: Re: State of the new config & build system In-Reply-To: <20011227195738.A26889@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Dec 2001, Eric S. Raymond wrote: > That is such an unutterably horrible concept that the very tentacles > of Cthulhu himself must twitch in dread at the thought. The last thing > anyone sane wants to do is have to maintain two parallel build systems > at the same time. Funny, I could have sworn I read this was Keith's intention at least for a few pre's. Maybe I misinterpreted his intentions. Dave. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:31:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:31:32 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:47366 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Thu, 27 Dec 2001 20:31:12 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Dave Jones Cc: "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 01:54:42 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Dec 2001 12:30:54 +1100 Message-ID: <18502.1009503054@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001 01:54:42 +0100 (CET), Dave Jones wrote: >On Thu, 27 Dec 2001, Eric S. Raymond wrote: > >> ..., and Keith's stuff is stable >> enough that he's now adding features like kernel-image type selection >> that were obviously way down his to-do list. > >How far down the list was "make it not take twice as long >to build the kernel as kbuild 2.4" ? Keith mentioned O(n^2) >effects due to each compile operation needing to reload >the dependancies etc. I had to choose between helping other architectures to convert and rewriting the core code to speed everything up. I chose to get other architectures converted, finding some interesting "features" at the same time. The core code is stable and I will not change it right now, I want stable code to go to Linus. Once Linus takes kbuild 2.5 then I can start on the rewrite, without affecting anybody else. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:38:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:37:53 -0500 Received: from bitmover.com ([192.132.92.2]:60063 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Thu, 27 Dec 2001 20:37:46 -0500 Date: Thu, 27 Dec 2001 17:37:39 -0800 From: Larry McVoy To: Keith Owens Cc: Larry McVoy , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011227173739.U25698@work.bitmover.com> Mail-Followup-To: Keith Owens , Larry McVoy , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011227171545.T25698@work.bitmover.com> <18619.1009503350@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <18619.1009503350@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Fri, Dec 28, 2001 at 12:35:50PM +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 12:35:50PM +1100, Keith Owens wrote: > On Thu, 27 Dec 2001 17:15:45 -0800, > Larry McVoy wrote: > >[talking about kbuild 2.5 speed] > >Then it does seem reasonable to ask that the new one is at least as fast > >as the old one. > > kbuild 2.4 is fast but inaccurate, kbuild 2.5 is slower but accurate. > Pick one. > > I am sure that I can speed up kbuild 2.5 with a rewrite of the core > code but I am staying on stable code to send to Linus. A couple of questions: a) will 2.5 be as fast as the current system? Faster? b) what's the eta on 2.5? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:40:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:39:55 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:59398 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Thu, 27 Dec 2001 20:38:49 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Dave Jones Cc: "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , Linux Kernel Mailing List , kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 02:22:01 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Dec 2001 12:38:37 +1100 Message-ID: <18645.1009503517@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001 02:22:01 +0100 (CET), Dave Jones wrote: >On Thu, 27 Dec 2001, Eric S. Raymond wrote: > >> That is such an unutterably horrible concept that the very tentacles >> of Cthulhu himself must twitch in dread at the thought. The last thing >> anyone sane wants to do is have to maintain two parallel build systems >> at the same time. > >Funny, I could have sworn I read this was Keith's intention at least >for a few pre's. Maybe I misinterpreted his intentions. Only long enough to prove that kbuild 2.5 built kernels that worked. And to give unconverted architectures a kernel that had both old and new kbuild in it for their conversion. Once kbuild 2.5 has proved it works, kbuild 2.4 is coming out. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:36:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:36:14 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:54278 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Thu, 27 Dec 2001 20:36:03 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Larry McVoy Cc: "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Thu, 27 Dec 2001 17:15:45 -0800." <20011227171545.T25698@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Dec 2001 12:35:50 +1100 Message-ID: <18619.1009503350@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Dec 2001 17:15:45 -0800, Larry McVoy wrote: >[talking about kbuild 2.5 speed] >Then it does seem reasonable to ask that the new one is at least as fast >as the old one. kbuild 2.4 is fast but inaccurate, kbuild 2.5 is slower but accurate. Pick one. I am sure that I can speed up kbuild 2.5 with a rewrite of the core code but I am staying on stable code to send to Linus. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:37:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:37:37 -0500 Received: from cpe-24-221-152-185.az.sprintbbd.net ([24.221.152.185]:3728 "EHLO opus.bloom.county") by vger.kernel.org with ESMTP id ; Thu, 27 Dec 2001 20:37:22 -0500 Date: Thu, 27 Dec 2001 18:36:54 -0700 From: Tom Rini To: Dave Jones Cc: "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , Linux Kernel Mailing List , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011228013654.GK712@cpe-24-221-152-185.az.sprintbbd.net> In-Reply-To: <20011227195738.A26889@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 02:22:01AM +0100, Dave Jones wrote: > On Thu, 27 Dec 2001, Eric S. Raymond wrote: > > > That is such an unutterably horrible concept that the very tentacles > > of Cthulhu himself must twitch in dread at the thought. The last thing > > anyone sane wants to do is have to maintain two parallel build systems > > at the same time. > > Funny, I could have sworn I read this was Keith's intention at least > for a few pre's. Maybe I misinterpreted his intentions. I think Keith wanted a very small time window tho (~24 hrs, barring big supprises). But if we're going to be worried about the build time, kbuild-2.5 and cml2 aren't co-dependant, yes? I know kbuild-2.5 works w/o cml2, and last I tried (ages ago admitedly) cml2 didn't need kbuild-2.5. So we could, in theory dump cml1 quickly but leave the old Makefiles for a bit longer. Or if Keith thinks he can start on the speed problems soon, just plod along for a few releases. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:42:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:42:23 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:65030 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Thu, 27 Dec 2001 20:42:00 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Larry McVoy Cc: "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Thu, 27 Dec 2001 17:37:39 -0800." <20011227173739.U25698@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Dec 2001 12:41:48 +1100 Message-ID: <18754.1009503708@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Dec 2001 17:37:39 -0800, Larry McVoy wrote: >A couple of questions: > >a) will 2.5 be as fast as the current system? Faster? At the moment kbuild 2.5 ranges from 10% faster on small builds to 100% slower on a full kernel build. But that is using slow core code which I know I can rewrite to make it significantly faster. >b) what's the eta on 2.5? kbuild 2.5 is ready now. I am not even going to start on the core rewrite until Linus takes the existing kbuild 2.5 code. The existing code works and is stable, doing a complete core rewrite just before includeing in the kernel strikes me as stupid. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:47:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:47:32 -0500 Received: from bitmover.com ([192.132.92.2]:1184 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Thu, 27 Dec 2001 20:47:28 -0500 Date: Thu, 27 Dec 2001 17:47:23 -0800 From: Larry McVoy To: Keith Owens Cc: Larry McVoy , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011227174723.V25698@work.bitmover.com> Mail-Followup-To: Keith Owens , Larry McVoy , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011227173739.U25698@work.bitmover.com> <18754.1009503708@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <18754.1009503708@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Fri, Dec 28, 2001 at 12:41:48PM +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 12:41:48PM +1100, Keith Owens wrote: > On Thu, 27 Dec 2001 17:37:39 -0800, > Larry McVoy wrote: > >A couple of questions: > > > >a) will 2.5 be as fast as the current system? Faster? > > At the moment kbuild 2.5 ranges from 10% faster on small builds to 100% > slower on a full kernel build. I don't understand why it would be slower. Maybe I'm clueless but I thought you were moving more towards a single makefile system, kind of like what BSD had about 15 years ago, you went to /sys/MYMACHINE and typed make and it did the build completely in that directory. You did different configs by running a configure tool that made /sys/MYMACHINE /sys/YOURMACHINE, etc. If this is the general approach, shouldn't this be a lot faster than the current approach? The current approach stats stuff many times. Linux is really good at making stats cheap, but nothing is as good as not doing it twice. Am I completely misunderstanding what kbuild is all about? My apologies if so... -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:52:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:52:32 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:1744 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Thu, 27 Dec 2001 20:52:24 -0500 Date: Thu, 27 Dec 2001 20:36:45 -0500 From: "Eric S. Raymond" To: Tom Rini Cc: Dave Jones , Linus Torvalds , Marcelo Tosatti , Linux Kernel Mailing List , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011227203645.A28510@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Tom Rini , Dave Jones , Linus Torvalds , Marcelo Tosatti , Linux Kernel Mailing List , kbuild-devel@lists.sourceforge.net In-Reply-To: <20011227195738.A26889@thyrsus.com> <20011228013654.GK712@cpe-24-221-152-185.az.sprintbbd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011228013654.GK712@cpe-24-221-152-185.az.sprintbbd.net>; from trini@kernel.crashing.org on Thu, Dec 27, 2001 at 06:36:54PM -0700 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Tom Rini : > I think Keith wanted a very small time window tho (~24 hrs, barring big > supprises). But if we're going to be worried about the build time, > kbuild-2.5 and cml2 aren't co-dependant, yes? I know kbuild-2.5 works > w/o cml2, and last I tried (ages ago admitedly) cml2 didn't need > kbuild-2.5. That's right. CML2 and kbuild-2.5 do not require each other > So we could, in theory dump cml1 quickly but leave the old > Makefiles for a bit longer. Or if Keith thinks he can start on the > speed problems soon, just plod along for a few releases. :) As Keith has pointed out, old kbuild achieves its speed by being broken. That's an argument for "plod along", IMHO. -- Eric S. Raymond (Those) who are trying to read the Second Amendment out of the Constitution by claiming it's not an individual right (are) courting disaster by encouraging others to use the same means to eliminate portions of the Constitution they don't like. -- Alan Dershowitz, Harvard Law School From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 20:58:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 20:58:23 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:22791 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Thu, 27 Dec 2001 20:58:13 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Larry McVoy Cc: "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Thu, 27 Dec 2001 17:47:23 -0800." <20011227174723.V25698@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Dec 2001 12:57:58 +1100 Message-ID: <19047.1009504678@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Dec 2001 17:47:23 -0800, Larry McVoy wrote: >On Fri, Dec 28, 2001 at 12:41:48PM +1100, Keith Owens wrote: >> On Thu, 27 Dec 2001 17:37:39 -0800, >> Larry McVoy wrote: >> >A couple of questions: >> > >> >a) will 2.5 be as fast as the current system? Faster? >> >> At the moment kbuild 2.5 ranges from 10% faster on small builds to 100% >> slower on a full kernel build. > >I don't understand why it would be slower. Maybe I'm clueless but I thought >you were moving more towards a single makefile system It uses a single generated Makefile, that is not the problem. The slow code is extracting the dependencies. Unlike the broken make dep, kbuild 2.5 extracts accurate dependencies by using the -MD option of cpp and post processing the cpp list. The post processing code is slow because the current design requires every compile to read a complete list of all the files, giving O(n^2) effects. Mark 2 of the core code will use a shared database with concurrent update so post processing is limited to looking up just the required files, instead of reading the complete list every time. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 21:02:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 21:02:03 -0500 Received: from bitmover.com ([192.132.92.2]:9632 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Thu, 27 Dec 2001 21:01:52 -0500 Date: Thu, 27 Dec 2001 18:01:48 -0800 From: Larry McVoy To: Keith Owens Cc: Larry McVoy , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011227180148.A3727@work.bitmover.com> Mail-Followup-To: Keith Owens , Larry McVoy , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011227174723.V25698@work.bitmover.com> <19047.1009504678@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <19047.1009504678@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Fri, Dec 28, 2001 at 12:57:58PM +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > Unlike the broken make dep, kbuild 2.5 extracts accurate dependencies > by using the -MD option of cpp and post processing the cpp list. The > post processing code is slow because the current design requires every > compile to read a complete list of all the files, giving O(n^2) > effects. Mark 2 of the core code will use a shared database with > concurrent update so post processing is limited to looking up just the > required files, instead of reading the complete list every time. Ah, OK, I get it. Hey, would it help to have a dbm interface compat library which uses mmap instead of building the db in brk() space? We've got a small, fast one that you can have under any license you like, GPL, LGPL, whatever. We use it all over the BK code. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 04:27:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 04:27:06 -0500 Received: from panic.ohr.gatech.edu ([130.207.47.194]:17319 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 04:26:49 -0500 Date: Fri, 28 Dec 2001 04:26:48 -0500 From: Legacy Fishtank To: Dave Jones Cc: "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228042648.A7943@havoc.gtf.org> In-Reply-To: <200112280024.fBS0OYH26337@snark.thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from davej@suse.de on Fri, Dec 28, 2001 at 01:54:42AM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 01:54:42AM +0100, Dave Jones wrote: > How far down the list was "make it not take twice as long > to build the kernel as kbuild 2.4" ? Keith mentioned O(n^2) > effects due to each compile operation needing to reload > the dependancies etc. Each compile needs to reload deps??? Ug. IMHO if you are doing to shake up the entire build system, you should Do It Right(tm) and build a -complete- dependency graph -once-. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 04:43:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 04:43:07 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:17931 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 04:43:01 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Legacy Fishtank Cc: Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 04:26:48 CDT." <20011228042648.A7943@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Dec 2001 20:42:44 +1100 Message-ID: <2705.1009532564@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001 04:26:48 -0500, Legacy Fishtank wrote: >On Fri, Dec 28, 2001 at 01:54:42AM +0100, Dave Jones wrote: >> How far down the list was "make it not take twice as long >> to build the kernel as kbuild 2.4" ? Keith mentioned O(n^2) >> effects due to each compile operation needing to reload >> the dependancies etc. > >Each compile needs to reload deps??? > >Ug. IMHO if you are doing to shake up the entire build system, you >should Do It Right(tm) and build a -complete- dependency graph -once-. We have one complete dependency graph for the explicit dependencies. What is slow is extracting the implicit dependencies after an object has been compiled, i.e. the files that it includes. Actually extracting the implicit dependencies is fast, converting them to standard names is fast, what is slow is _reading_ the big list that maps from absolute names to standardized names. I need the big list in order to remove absolute names in the dependency trees. kbuild 2.4 forces a complete recompile if you rename a tree, including if you build on one system then try to install via NFS on a second system. kbuild 2.5 can cope with trees being renamed and trees having different names on local and NFS mounted systems. That flexibility comes at a cost. "All" I need to do is have one server process that reads the big list once and the other client processes talk to the server. Much less data involved means faster conversion from absolute to standardized names. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 09:05:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 09:05:46 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:35592 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 09:05:33 -0500 Subject: Re: State of the new config & build system To: lm@bitmover.com (Larry McVoy) Date: Fri, 28 Dec 2001 14:14:37 +0000 (GMT) Cc: kaos@ocs.com.au (Keith Owens), lm@bitmover.com (Larry McVoy), esr@thyrsus.com (Eric S. Raymond), davej@suse.de (Dave Jones), esr@snark.thyrsus.com (Eric S. Raymond), torvalds@transmeta.com (Linus Torvalds), marcelo@conectiva.com.br (Marcelo Tosatti), linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011227180148.A3727@work.bitmover.com> from "Larry McVoy" at Dec 27, 2001 06:01:48 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > Ah, OK, I get it. Hey, would it help to have a dbm interface compat > library which uses mmap instead of building the db in brk() space? mmap for db file seems to be slower. For basic db hash usage and raw speed nothing seems to touch tdb (Tridge's db hack). Its also portable code which is important since the tool has to be built on the compiling host. Personally I've always considered make dep good enough. Its trying to solve the extra .5% that probably can be solved by careful use of make clean when CML realises a critical rule changed (SMP etc) Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 09:15:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 09:15:28 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:41736 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 09:15:25 -0500 Subject: Re: State of the new config & build system To: kaos@ocs.com.au (Keith Owens) Date: Fri, 28 Dec 2001 14:24:35 +0000 (GMT) Cc: lm@bitmover.com (Larry McVoy), esr@thyrsus.com (Eric S. Raymond), davej@suse.de (Dave Jones), esr@snark.thyrsus.com (Eric S. Raymond), torvalds@transmeta.com (Linus Torvalds), marcelo@conectiva.com.br (Marcelo Tosatti), linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <18754.1009503708@ocs3.intra.ocs.com.au> from "Keith Owens" at Dec 28, 2001 12:41:48 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > At the moment kbuild 2.5 ranges from 10% faster on small builds to 100% > slower on a full kernel build. But that is using slow core code which > kbuild 2.5 is ready now. I am not even going to start on the core "Its 100% slower so its ready" I must be missing something here. If its 100% slower its not ready. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 09:17:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 09:17:18 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:8461 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 09:17:13 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alan Cox Cc: lm@bitmover.com (Larry McVoy), esr@thyrsus.com (Eric S. Raymond), davej@suse.de (Dave Jones), esr@snark.thyrsus.com (Eric S. Raymond), torvalds@transmeta.com (Linus Torvalds), marcelo@conectiva.com.br (Marcelo Tosatti), linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 14:14:37 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Dec 2001 01:16:57 +1100 Message-ID: <4481.1009549017@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001 14:14:37 +0000 (GMT), Alan Cox wrote: >> Ah, OK, I get it. Hey, would it help to have a dbm interface compat >> library which uses mmap instead of building the db in brk() space? > >mmap for db file seems to be slower. For basic db hash usage and raw speed >nothing seems to touch tdb (Tridge's db hack). Its also portable code which >is important since the tool has to be built on the compiling host. lm sent me the bk mdbm code but I will look at tdb as well. Four acronyms in one sentance, I must be a phb :). >Personally I've always considered make dep good enough. Its trying to solve >the extra .5% that probably can be solved by careful use of make clean when >CML realises a critical rule changed (SMP etc) http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2 Especially makefile-2.5_make_dep.html, 9 reasons why make dep is broken as designed. Some are fixable in the current system, others are inherently unfixable. I skipped that page when I did my presentation at the 2.5 developer's conference. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 11:25:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 11:25:36 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:37641 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 11:25:23 -0500 Subject: Re: State of the new config & build system To: kaos@ocs.com.au (Keith Owens) Date: Fri, 28 Dec 2001 16:34:43 +0000 (GMT) Cc: garzik@havoc.gtf.org (Legacy Fishtank), davej@suse.de (Dave Jones), esr@snark.thyrsus.com (Eric S. Raymond), torvalds@transmeta.com (Linus Torvalds), marcelo@conectiva.com.br (Marcelo Tosatti), linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <2705.1009532564@ocs3.intra.ocs.com.au> from "Keith Owens" at Dec 28, 2001 08:42:44 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > including if you build on one system then try to install via NFS on a > second system. kbuild 2.5 can cope with trees being renamed and trees > having different names on local and NFS mounted systems. That > flexibility comes at a cost. So you've halved performance rather than documented that you have to mount the tree in the space place on every NFS export ? I'm obviously still missing something here. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 12:14:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 12:14:19 -0500 Received: from hog.ctrl-c.liu.se ([130.236.252.129]:56328 "HELO hog.ctrl-c.liu.se") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 12:14:05 -0500 To: kaos@ocs.com.au Cc: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system Newsgroups: linux.kernel In-Reply-To: <4481.1009549017@ocs3.intra.ocs.com.au> In-Reply-To: Organization: Message-Id: <20011228171403.58F6636DE6@hog.ctrl-c.liu.se> Date: Fri, 28 Dec 2001 18:14:03 +0100 (CET) From: wingel@hog.ctrl-c.liu.se (Christer Weinigel) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In article <4481.1009549017@ocs3.intra.ocs.com.au> you write: >Alan Cox wrote: >>Personally I've always considered make dep good enough. Its trying to solve >>the extra .5% that probably can be solved by careful use of make clean when >>CML realises a critical rule changed (SMP etc) > >http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2 >Especially makefile-2.5_make_dep.html, 9 reasons why make dep is broken >as designed. Some are fixable in the current system, others are >inherently unfixable. I skipped that page when I did my presentation >at the 2.5 developer's conference. * make dep is only run once Personally, I don't see this as a big problem. Just tell people to always run "make oldconfig && make dep" after patching the kernel and if they can't read, too bad. I usually compile a kernel a lot more often than I add include files. Since I'm quite impatient I often do "make SUBDIRS=drivers/mtd/maps modules" just so that the compile will go faster, so having to do dependency checking each time I want to compile feels like an unfortunate tradeoff to me. * The generated dependencies are absolute That dependencies are absolute is also not a thing that has bothered me too much, it's always possible to run "make dep" after moving a tree, on the other hand, I don't use NFS a lot anymore, so I can see it being a problem in other environments. /Christer -- "Just how much can I get away with and still go to heaven?" From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 12:32:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 12:32:30 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:10250 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 12:32:18 -0500 Subject: Re: State of the new config & build system To: wingel@hog.ctrl-c.liu.se (Christer Weinigel) Date: Fri, 28 Dec 2001 17:39:08 +0000 (GMT) Cc: kaos@ocs.com.au, linux-kernel@vger.kernel.org In-Reply-To: <20011228171403.58F6636DE6@hog.ctrl-c.liu.se> from "Christer Weinigel" at Dec 28, 2001 06:14:03 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > * make dep is only run once > > Personally, I don't see this as a big problem. Just tell people to I run make dep whenever I change config. Guess what - one cmp and I can automate that as part of make. If the .config doesnt match the .configwhendep then its time to make dep again > That dependencies are absolute is also not a thing that has bothered me > too much, it's always possible to run "make dep" after moving a tree, > on the other hand, I don't use NFS a lot anymore, so I can see it being > a problem in other environments. sed works too, as do symlinks From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 12:43:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 12:43:32 -0500 Received: from bitmover.com ([192.132.92.2]:45218 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 12:43:23 -0500 Date: Fri, 28 Dec 2001 09:43:19 -0800 From: Larry McVoy To: Alan Cox Cc: Larry McVoy , Keith Owens , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228094318.B3727@work.bitmover.com> Mail-Followup-To: Alan Cox , Larry McVoy , Keith Owens , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011227180148.A3727@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Dec 28, 2001 at 02:14:37PM +0000 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 02:14:37PM +0000, Alan Cox wrote: > > Ah, OK, I get it. Hey, would it help to have a dbm interface compat > > library which uses mmap instead of building the db in brk() space? > > mmap for db file seems to be slower. I'll need to see some numbers to back up that statement, please. If you look at the graphs produced by LMbench, they tell you exactly what you need to know. It's true that for very small files, 8K and under, using read() to access them is faster than using mmap, due to the extra work of setting up and tearing down the mapping. To quantify this, a 4KB open/read/close is 500MB/sec, but an open/mmap/access/unmap/close is 425MB/sec. By the time we hit 16K, mmap wins by 15% and just gets better from there. And that all assumes you are doing large reads, which in db code you are not. So mmap will look better even on the small files if you are doing little DB style accesses. > For basic db hash usage and raw speed > nothing seems to touch tdb (Tridge's db hack). Taking nothing away from Tridge, I like Tridge, I'd like to see numbers. I'm sure that Tridge's stuff is great, but we were very motivated to go well beyond the normal effort when we wrote this code. A multithreaded version of the code that I sent to Keith was doing 455,000 lookups/second on an 8way 200Mhz R4400 SGI box in 1996. Each lookup was locked. If you assume perfect scaling (it was) and you assume the locks took 0 time (they didn't), that's 1.75 usecs for each lookup. On a machine with horrible memory latency and a large dataset. We designed the MDBM code to be scalable (its 64bit clean), portable (runs on 20+ platforms today), multiplatform (metadata is stored in network byte order on disk), and fast (we knew exactly what the instruction and data cache footprint was for hot cache, and we made sure that you did at most 2 disk accesses, 1 was typical, to get at any item in a cold cache). SGI uses this code for their name server, every process mmaps the name server cache. We use this code all over BitKeeper. > Its also portable code which > is important since the tool has to be built on the compiling host. The code works on Windows, MacOS X, and basically all Unix platforms. Yeah, yeah, I pounding my chest and I'm sorry, but I get beat up all the time that the BK license doesn't let you reuse code and this code is part of BK that we broke out and licensed under the GPL. The point being that if there is reusable code in BK, we're willing to let people use it under whatever license they want. It would be nice if that actually happened after all the yelling and screaming. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 13:05:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 13:04:51 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:38150 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 13:04:38 -0500 Date: Fri, 28 Dec 2001 10:02:01 -0800 (PST) From: Linus Torvalds To: Legacy Fishtank cc: Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , , Subject: Re: State of the new config & build system In-Reply-To: <20011228042648.A7943@havoc.gtf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org [ Btw, Jeff, any reason why you changed your name to "Legacy Fishtank"? It took a few mails before I noticed that it also said "garzik" in the fine print;] One thing that this big flame-war has brought up is that different people like different things. There may be a simpler solution to this: have the core dependency files generated from some other file format. My pet peeve is "centralized knowledge". I absolutely detested the first versions of cml2 for having a single config file, and quite frankly I don't think Eric has even _yet_ separated things out enough - why does the main "rules.cml" file have architecture-specific info, for example? That's a big step backwards as far as I'm concerned - we didn't use to have those stupid global files, and each architecture could do it's own config rules. Eric never got the point that to me, modularity is _the_ most important thing for maintenance. Something I also asked for the config system at least a year ago was to have Configure.help split up. Never happened. It's still one large ugly file. Driver or architecture maintainers still can't just change _their_ small fragment, they have to touch a global file that they don't "own". So if somebody really wants to help this, make scripts that generate config files AND Configure.help files from a distributed set. And once you do that, you could even imagine creating the old-style config files (without the automatic checking and losing some information) from the information. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 13:09:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 13:09:01 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:41994 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 13:08:59 -0500 Subject: Re: State of the new config & build system To: lm@bitmover.com (Larry McVoy) Date: Fri, 28 Dec 2001 18:17:57 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), lm@bitmover.com (Larry McVoy), kaos@ocs.com.au (Keith Owens), esr@thyrsus.com (Eric S. Raymond), davej@suse.de (Dave Jones), esr@snark.thyrsus.com (Eric S. Raymond), torvalds@transmeta.com (Linus Torvalds), marcelo@conectiva.com.br (Marcelo Tosatti), linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228094318.B3727@work.bitmover.com> from "Larry McVoy" at Dec 28, 2001 09:43:19 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > that if there is reusable code in BK, we're willing to let people use > it under whatever license they want. It would be nice if that actually > happened after all the yelling and screaming. mdbm is one I've not seen. The timings I've done are with db2/db3/tdb when I was playing with a fast UDP server that had to do a db lookup per packet. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 13:14:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 13:14:12 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:50186 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 13:14:00 -0500 Subject: Re: State of the new config & build system To: torvalds@transmeta.com (Linus Torvalds) Date: Fri, 28 Dec 2001 18:24:02 +0000 (GMT) Cc: garzik@havoc.gtf.org (Legacy Fishtank), davej@suse.de (Dave Jones), esr@snark.thyrsus.com (Eric S. Raymond), marcelo@conectiva.com.br (Marcelo Tosatti), linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: from "Linus Torvalds" at Dec 28, 2001 10:02:01 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > So if somebody really wants to help this, make scripts that generate > config files AND Configure.help files from a distributed set. And once you > do that, you could even imagine creating the old-style config files Something like: find $TOPDIR -name "*.cf" -exec cat {} \; > Configure.help or changing the tools to look for Documentation/Configure/CONFIG_SMALL_BANANA ?? Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 14:09:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 14:09:19 -0500 Received: from cmailg4.svr.pol.co.uk ([195.92.195.174]:32579 "EHLO cmailg4.svr.pol.co.uk") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 14:09:07 -0500 Posted-Date: Fri, 28 Dec 2001 19:08:54 GMT Date: Fri, 28 Dec 2001 19:08:54 +0000 (GMT) From: Riley Williams Reply-To: Riley Williams To: Linus Torvalds cc: Legacy Fishtank , Linux Kernel Subject: Re: State of the new config & build system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus. > [ Btw, Jeff, any reason why you changed your name to "Legacy > Fishtank"? It took a few mails before I noticed that it also said > "garzik" in the fine print;] I had wondered where he'd gone to - Jeff was one of the few from who I read every email, and it's been a while since I saw anything from him. > One thing that this big flame-war has brought up is that different > people like different things. There may be a simpler solution to > this: have the core dependency files generated from some other file > format. > > My pet peeve is "centralized knowledge". I absolutely detested the > first versions of cml2 for having a single config file, and quite > frankly I don't think Eric has even _yet_ separated things out > enough - why does the main "rules.cml" file have > architecture-specific info, for example? > > That's a big step backwards as far as I'm concerned - we didn't use > to have those stupid global files, and each architecture could do > it's own config rules. Eric never got the point that to me, > modularity is _the_ most important thing for maintenance. > > Something I also asked for the config system at least a year ago was > to have Configure.help split up. Never happened. It's still one > large ugly file. Driver or architecture maintainers still can't just > change _their_ small fragment, they have to touch a global file that > they don't "own". > > So if somebody really wants to help this, make scripts that generate > config files AND Configure.help files from a distributed set. And > once you do that, you could even imagine creating the old-style > config files (without the automatic checking and losing some > information) from the information. I offered to go through Configure.help and split it up a while back, and I was drowned in several dozen emails saying that such was a BAD THING, with absolutely zilch saying otherwise. I'm more than willing to have a go at splitting it up into separate files by directory, but before I do, I would need to know how you wished to deal with symbols that are referenced all over the source tree rather than just in a single directory. Another thing I'd like to do is to introduce a "boilerplate" mechanism whereby help text that's repeated in multiple options gets stored just once and dragged in when it's needed. I've made a start on doing that with the current Configure.help file and the `make config` and `make menuconfig` commands, and have patches available against the 2.0.39, 2.2.20 and 2.4.17 trees to provide the base implementation for `make config` but gather that such is pointless as those commands will soon be extracted from the Linux kernel. Best wishes from Riley. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 14:29:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 14:27:48 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:65497 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 14:27:33 -0500 Date: Fri, 28 Dec 2001 14:12:11 -0500 From: "Eric S. Raymond" To: Linus Torvalds Cc: Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228141211.B15338@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228042648.A7943@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from torvalds@transmeta.com on Fri, Dec 28, 2001 at 10:02:01AM -0800 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds : > My pet peeve is "centralized knowledge". I absolutely detested the first > versions of cml2 for having a single config file, and quite frankly I > don't think Eric has even _yet_ separated things out enough - why does the > main "rules.cml" file have architecture-specific info, for example? I'm not certain what you're objecting to, and I want to understand it. There are rules that use architecture symbols to suppress things like bus types. I presume that's not a problem for you, but tell me if it is. My best guess is that you're objecting to the archihacks and kernelhacking menus, or the architecture-dependent derivations down around line 330. In general what's going on here is actually the beginnings of an attempt to replace architecture-dependent questions with architecture-*independent* questions. It looks kind of ugly right now because it's too early in the game to mess with the config-symbol namespace -- but, for example, I want to merge the MATH_EMULATION and MATHEMU symbols eventually. And there ought to be a generic set of toggles for kernel-debugging that present to the user as cross-platform capabilities rather than platform- specific switches. In those two menus I've gathered together architecture-specific symbols that I think ought to merge into cross-platform capabilities. But I know there is other cruft in there for historical reasons. Since you've brought up the point, I'll do a cleanup pass on these and see how much I can exile to the arch/*/rules.cml files. There isn't really any help for the ceoss-platform derivations. There are exactly four of these. I've worked hard at holding them to a minimum: derive HAVE_DEC_LOCK from (SMP and (ALPHA or X86_CMPXCHG)) or SPARC or PPC derive HIGHMEM from HIGHMEM4G or HIGHMEM64G or SPARC derive MAC_HID from (ALL_PPC and INPUT!=n) or (MAC and INPUT_ADBHID) derive PC_KEYB from ARM_PC_KEYB or MIPS_PC_KEYB If you notice that each right-hand part includes port symbols from at least two different architectures, I think it will be clearer why these are necessary. CML1's way of doing this had the problem that it was hard to know by inspection of the rulebase under what circumstances a given symbol was actually turned on. This is why CML2 has a rule that each symbol is derived (or occurs in a menu) exactly once. With some work I could relax this restriction, but I don't want to -- it's a major factor in keeping the rulebase's complexity down in the range that a human brain can mentally model. > That's a big step backwards as far as I'm concerned - we didn't use to > have those stupid global files, and each architecture could do it's own > config rules. Eric never got the point that to me, modularity is _the_ > most important thing for maintenance. Oh, no, I got that all right. What I have been trying to do is trade off correctly between modularity (which helps maintenance) and the advantages to the configurator *users* of having a global capability namespace, single-apex menu structure, and the symbols-to-prompts mapping in one file. These choices weren't made at random. You don't readily see their advantages because you have a nose-to-the-code, maintainer perspective (quite properly so, in most cases). But in designing the configuration system, simplifying life for *users* is just as important, if not more so. Sometimes this implies not going as far in the direction you favor direction as you might like (monolithic Configure.help is an example). > Something I also asked for the config system at least a year ago was to > have Configure.help split up. Never happened. It's still one large ugly > file. Driver or architecture maintainers still can't just change _their_ > small fragment, they have to touch a global file that they don't "own". Yes, there are two reasons for this. The contingent, historical reason is that I wanted to get Configure.help in good shape before thinking about dispersing it. That work is now done (though you haven't kept up to date with it). The design reason is that having a single file with all the symbol-to-prompt mappings in it is really helpful when you want to localize the rulebase for another language. I'm still leaning towards keeping symbols.cml together just to make it easier for people to do and distribute translations of it. I think this is an issue that is rising in importance. I have no problem with assuming that kernel hackers are English-literate, but it's no longer an assumption we should make about people *building* kernels. I want to encourage CML2 and question-string localizations for French. And German. And Thai. And Ethiopian. -- Eric S. Raymond If I were to select a jack-booted group of fascists who are perhaps as large a danger to American society as I could pick today, I would pick BATF [the Bureau of Alcohol, Tobacco, and Firearms]. -- U.S. Representative John Dingell, 1980 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 15:01:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 15:01:29 -0500 Received: from bitmover.com ([192.132.92.2]:18339 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 15:01:10 -0500 Date: Fri, 28 Dec 2001 12:01:04 -0800 From: Larry McVoy To: Keith Owens Cc: Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228120104.B4077@work.bitmover.com> Mail-Followup-To: Keith Owens , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228042648.A7943@havoc.gtf.org> <2705.1009532564@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <2705.1009532564@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Fri, Dec 28, 2001 at 08:42:44PM +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 08:42:44PM +1100, Keith Owens wrote: > "All" I need to do is have one server process that reads the big list > once and the other client processes talk to the server. Much less data > involved means faster conversion from absolute to standardized names. Actually, if you use the mdbm code, you can have a server process which reads the data, stashes it in the db, touchs ./i_am_done, and exits. "client" processes do a while (!exists("i_am_done")) usleep(100000); m = mdbm_open("db", O_RDONLY, 0, 0); val = mdbm_fetch_str(m, "key"); etc. No sockets, no back and forth, runs at mmap speed. If you tell me what the data looks like that needs to be in the DB, i.e., how to get it, I'll code you up the "server" side. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 15:27:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 15:26:40 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:46070 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 15:26:38 -0500 Date: Fri, 28 Dec 2001 15:26:32 -0500 (EST) From: Alexander Viro To: "Eric S. Raymond" cc: Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: <20011228141211.B15338@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001, Eric S. Raymond wrote: > The design reason is that having a single file with all the symbol-to-prompt > mappings in it is really helpful when you want to localize the rulebase for > another language. I'm still leaning towards keeping symbols.cml together > just to make it easier for people to do and distribute translations of it. > > I think this is an issue that is rising in importance. I have no problem > with assuming that kernel hackers are English-literate, but it's no longer > an assumption we should make about people *building* kernels. I want > to encourage CML2 and question-string localizations for French. And > German. And Thai. And Ethiopian. You are nuts. OK, you've got these translations. Now what? $FOO adds a new option. Should he, by any chance, supply all relevant translations in the same patch? No? Good, so we are going to have them permanently out of sync. Better yet, option changes its meaning. Now we have English variant with new semantics and Thai one with the old. Happy, happy, joy, joy... And that's aside of the real problem with "internationalization" - quality of translations _sucks_. Always. Yes, USAnian to English is easy. But that's it. I've tried to use LANG=ru_RU.koi8-r. It had lasted a couple of days. You end up reconstructing the English original and translating it to Russian - and boy, does that process annoy... Frankly, I find it very amusing that advocates of i18n efforts tend to be either British or USAnians. Folks, get real - your languages are too close to show where the problems are. I can see how doing that gives you a warm fuzzy feeling, but could you please listen to those of us who have to deal with the resulting mess for real? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 15:39:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 15:39:13 -0500 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:201 "EHLO vindaloo.ras.ucalgary.ca") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 15:38:58 -0500 Date: Fri, 28 Dec 2001 13:38:41 -0700 Message-Id: <200112282038.fBSKcfX11474@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Larry McVoy Cc: Keith Owens , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: <20011228120104.B4077@work.bitmover.com> In-Reply-To: <20011228042648.A7943@havoc.gtf.org> <2705.1009532564@ocs3.intra.ocs.com.au> <20011228120104.B4077@work.bitmover.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Larry McVoy writes: > On Fri, Dec 28, 2001 at 08:42:44PM +1100, Keith Owens wrote: > > "All" I need to do is have one server process that reads the big list > > once and the other client processes talk to the server. Much less data > > involved means faster conversion from absolute to standardized names. > > Actually, if you use the mdbm code, you can have a server process which > reads the data, stashes it in the db, touchs ./i_am_done, and exits. > "client" processes do a > > while (!exists("i_am_done")) usleep(100000); > m = mdbm_open("db", O_RDONLY, 0, 0); > val = mdbm_fetch_str(m, "key"); > etc. > > No sockets, no back and forth, runs at mmap speed. That sounds like a better approach. I got a bit nervous when Keith talked about a "server process". Made me think I'm going to have to install some daemon, or I'm going to have a pile of background processes being left behind (no matter how careful you are, you always end up with some "leakage" of stale processes). Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 15:45:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 15:45:25 -0500 Received: from panic.ohr.gatech.edu ([130.207.47.194]:40118 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 15:44:39 -0500 Date: Fri, 28 Dec 2001 15:41:51 -0500 From: Legacy Fishtank To: Linus Torvalds Cc: Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228154151.B27313@havoc.gtf.org> In-Reply-To: <20011228042648.A7943@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from torvalds@transmeta.com on Fri, Dec 28, 2001 at 10:02:01AM -0800 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 10:02:01AM -0800, Linus Torvalds wrote: > Something I also asked for the config system at least a year ago was to > have Configure.help split up. Never happened. It's still one large ugly > file. Driver or architecture maintainers still can't just change _their_ > small fragment, they have to touch a global file that they don't "own". > > So if somebody really wants to help this, make scripts that generate > config files AND Configure.help files from a distributed set. And once you > do that, you could even imagine creating the old-style config files > (without the automatic checking and losing some information) from the > information. For single-file drivers, I like Becker's (correct credit?) system... about 10 lines of metadata is embedded in a C comment, and it includes the Config.in and Configure.help info. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 15:43:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 15:43:01 -0500 Received: from panic.ohr.gatech.edu ([130.207.47.194]:36022 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 15:42:53 -0500 Date: Fri, 28 Dec 2001 15:39:39 -0500 From: Legacy Fishtank To: Linus Torvalds Cc: Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228153939.A27313@havoc.gtf.org> In-Reply-To: <20011228042648.A7943@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from torvalds@transmeta.com on Fri, Dec 28, 2001 at 10:02:01AM -0800 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 10:02:01AM -0800, Linus Torvalds wrote: > [ Btw, Jeff, any reason why you changed your name to "Legacy Fishtank"? It > took a few mails before I noticed that it also said "garzik" in the > fine print;] Away-from-home account and a long story :) Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 15:55:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 15:55:10 -0500 Received: from bitmover.com ([192.132.92.2]:43171 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 15:54:56 -0500 Date: Fri, 28 Dec 2001 12:54:51 -0800 From: Larry McVoy To: Alan Cox , Larry McVoy , Keith Owens , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228125451.E4077@work.bitmover.com> Mail-Followup-To: Alan Cox , Larry McVoy , Keith Owens , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011227180148.A3727@work.bitmover.com> <20011228094318.B3727@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20011228094318.B3727@work.bitmover.com>; from lm@bitmover.com on Fri, Dec 28, 2001 at 09:43:19AM -0800 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org More numbers. I coded up a little program (included below) which reads paths from stdin, lstats() them, and builds an MDBM of inode -> pathname entries. I ran that 10 times on the 2.4 kernel, which had 8679 files matching *.[chSs]. I did a little tuning of page size and inital DB size (reduces page split costs) and got it down to 105 millisecs from 200, so we're at 12 usecs per item. Then I removed the mdbm_store() call so I was doing everything except that. That took 7 usecs/item. Write path summary: the mdbm_store() cost is about 5 usecs/item, which is about right. To build a DB of the same number of items as source files in the kernel should cost less than 50 milliseconds for the DB part of the work. In other words, it's basically free. OK, on to the read path. I generated the list of inodes as an ascii file and wrote another program to open the mdbm and fetch each one. Ran that 10 times, it cost 40 milliseconds to look up all the items, so that's about 4 usecs/item including the read of the data from stdin. That's slower than I think it should be and I may go look to see what is going on, but it's plenty fast for the config/build system. Here's the code. Sorry about the perlisms, wait, no I'm not, I like those, but it will make you look at it twice before it makes sense. ------------------------------------------------------------------------------ /* * inode.c - create an MDBM of inode -> path mappings */ #include #include #include #include #include #include "mdbm.h" #define unless(x) if (!(x)) #define fnext(buf, f) fgets(buf, sizeof(buf), f) #define u32 unsigned int void chomp(char *s) { unless (s && *s) return; while (*s && (*s != '\n')) s++; *s = 0; } u32 inode(char *path) { struct stat sb; if (lstat(path, &sb)) return (0); return ((u32)sb.st_ino); } int main() { char buf[1024]; MDBM *m; datum k, v; u32 ino; unlink("ino.mdbm"); unless (m = mdbm_open("ino.mdbm", O_RDWR|O_CREAT, 0644, 4<<10)) { perror("ino.mdbm"); exit(1); } mdbm_pre_split(m, 128); while (fnext(buf, stdin)) { chomp(buf); unless (ino = inode(buf)) { perror(buf); continue; } printf("%u\n", ino); k.dptr = (void*)&ino; k.dsize = sizeof(u32); v.dptr = buf; v.dsize = strlen(buf) + 1; if (mdbm_store(m, k, v, MDBM_INSERT)) { perror(buf); exit(1); } } mdbm_close(m); exit(0); } ------------------------------------------------------------------------------ /* * read.c - read items from the mdbm */ #include #include #include #include #include #include "mdbm.h" #define unless(x) if (!(x)) #define fnext(buf, f) fgets(buf, sizeof(buf), f) #define u32 unsigned int int main() { char buf[1024]; MDBM *m; datum k, v; u32 ino; unless (m = mdbm_open("ino.mdbm", O_RDONLY, 0644, 0)) { perror("ino.mdbm"); exit(1); } while (fnext(buf, stdin)) { ino = atoi(buf); continue; k.dptr = (void*)&ino; k.dsize = sizeof(u32); v = mdbm_fetch(m, k); unless (v.dsize) { perror(buf); exit(1); } } mdbm_close(m); exit(0); } From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 15:55:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 15:55:00 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:18394 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 15:54:43 -0500 Date: Fri, 28 Dec 2001 15:39:02 -0500 From: "Eric S. Raymond" To: Alexander Viro Cc: Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228153902.B17774@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alexander Viro , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228141211.B15338@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from viro@math.psu.edu on Fri, Dec 28, 2001 at 03:26:32PM -0500 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alexander Viro : > > I think this is an issue that is rising in importance. I have no problem > > with assuming that kernel hackers are English-literate, but it's no longer > > an assumption we should make about people *building* kernels. I want > > to encourage CML2 and question-string localizations for French. And > > German. And Thai. And Ethiopian. > > You are nuts. OK, you've got these translations. Now what? $FOO adds > a new option. Should he, by any chance, supply all relevant translations > in the same patch? No? No. The usual way to handle this, of course, is to fall back on the English where you don't have translations. Imperfect, but liveable. > Good, so we are going to have them permanently > out of sync. Better yet, option changes its meaning. Now we have > English variant with new semantics and Thai one with the old. Happy, > happy, joy, joy... Which is why there are organized translation groups that do periodic translation updates for software that has registered with them. This doesn't eliminate the problem, but it can keep it within manageable bounds that make having localizations better than not. I deal with this regularly with respect to fetchmail. Anyway, options change semantics only very rarely in the kernel rulebase. Trust me on this as I've been maintaining the CML2 rulebase for 18 months; I have a better handle on the frequency of these events than *anyone* else. You are worrying about a non-problem in this case. > And that's aside of the real problem with "internationalization" - quality > of translations _sucks_. Always. No, not always. I read French, Italian, and Spanish; I can puzzle out technical prose in a couple of other languages. I can read fetchmail's .po files and *see* that they don't suck. > Frankly, I find it very amusing that advocates of i18n efforts tend to > be either British or USAnians. That's not my experience. I've had technical problems with GNU gettext (unrelated to quality of translation) severe enough that I've come very close to dropping localization support twice. The people who plead with me not to drop it have been non-Anglophones. It may be that the reason our experiences have been different is because we focus on different target languages. But I think my experience is an existence proof that there *is* demand for localization and that meeting it can have useful results. -- Eric S. Raymond I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 16:01:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 16:00:52 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:21466 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 16:00:45 -0500 Date: Fri, 28 Dec 2001 15:45:37 -0500 From: "Eric S. Raymond" To: Legacy Fishtank Cc: Linus Torvalds , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228154537.E17774@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Legacy Fishtank , Linus Torvalds , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228042648.A7943@havoc.gtf.org> <20011228154151.B27313@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011228154151.B27313@havoc.gtf.org>; from garzik@havoc.gtf.org on Fri, Dec 28, 2001 at 03:41:51PM -0500 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Legacy Fishtank : > For single-file drivers, I like Becker's (correct credit?) system... > about 10 lines of metadata is embedded in a C comment, and it includes > the Config.in and Configure.help info. I proposed implementing something like this about a year ago (to replace the nasty centralized knowledge in the MAINTAINERS and CREDITS files) and was shot down. I'd be happy to take another swing at this problem once the kbuild-2.5/CML2 transition is done. But I don't think we should let it block us from having the good results we can get from that change. -- Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 15:58:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 15:57:41 -0500 Received: from d-dialin-2988.addcom.de ([213.61.82.108]:17137 "EHLO localhost.localdomain") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 15:57:35 -0500 Date: Fri, 28 Dec 2001 21:56:53 +0100 (CET) From: Kai Germaschewski X-X-Sender: To: Keith Owens cc: Larry McVoy , "Eric S. Raymond" , Dave Jones , Linus Torvalds , Marcelo Tosatti , , Subject: Re: State of the new config & build system In-Reply-To: <18619.1009503350@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org [So far, I've generally been trying to keep away from the hot topics, but I guess it's about time to make that experience. Also, let me add that my opinion here is of course influenced by the fact that things didn't go the way I would have liked...] On Fri, 28 Dec 2001, Keith Owens wrote: > On Thu, 27 Dec 2001 17:15:45 -0800, > Larry McVoy wrote: > >[talking about kbuild 2.5 speed] > >Then it does seem reasonable to ask that the new one is at least as fast > >as the old one. > > kbuild 2.4 is fast but inaccurate, kbuild 2.5 is slower but accurate. > Pick one. Most problems which exist within kbuild 2.4 are fixable without the elaborate rewrite Keith did. The single biggest problem the current system has is that modversions get screwed up, since dependencies are screwed up, and yes, that's not easily fixable. However, this problem isn't even attacked in kbuild 2.5 AFAIK (I think modversions are simply disabled there). A couple of months ago, I came up with an alternative to kbuild 2.5. It doesn't try to have all the features kbuild 2.5 has, but solves the major problems with kbuild 2.4. It definitely has things in common with kbuild 2.5, it also uses the "non-recursive" approach, i.e. the top level Makefile includes all the others. It also doesn't have "make dep" but builds dependencies with "gcc -MD" plus postprocessing. I'm not claiming it is complete, and it doesn't even try to add the multiple source tree etc. features. Others said one should use proper version management instead, and I agree with that, but that's not the point. Non-complete list of pros/cons: o gets dependencies right, i.e. a new make "whatever" will really rebuild everything which is needed. Even *with* CONFIG_MODVERSIONS turned on. o uses standard tools. I believe people said that one of the advantages of UNIX is that you don't need specialized tools for everything, but combine existing tools to reach your goals. The new kbuild has the disadvantage that most is implemented from scratch, the meat is in C programs which probably nobody apart from Keith is familiar with. My solution used the standard tool for building, i.e. make + standard utilities like sh, sed, grep and the like. I only have one non-standard tool, that postprocesses a dependency list: replace include/linux/autoconf.h with the /include/linux/config/options - this is needed so that a .config change doesn't cause an entire rebuild every time. o It's actually pretty fast. On my laptop, the time to read all the dependencies when doing a "make bzImage modules" is was about 5 seconds with hot caches. That means a make takes about 5 seconds when there's nothing to do - that's good enough IMHO. When doing a full rebuild, the time spent within make is definitely down in the noise, if only a few files get rebuild, it's noticable, but still faster than what the current kbuild system gives. o The Makefiles in the SUBDIRS look basically the same as currently, only a somewhat simpler (no special $(LD) rules for composite objects etc). Keith implemented a whole new language - I supoose most coders are familiar with normal Makefiles, they have yet to learn the new commands in kbuild-2.5 (which, however, is easy, of course) o It's not nearly as feature-rich as Keith's approach is. o Behind the scenes, the code is not exactly clear. make is pretty flexible, but it really needs some hacks to do what's needed. So if someone wants to understand the build system, it takes some effort - same situation as in kbuild-2.4 and -2.5, though. o I had the major problems solved and things worked fine in my tree. However, I discontinued to work on it months ago, as I saw no way this work would ever be useful for other people - maintaining a build system just for personal use is a bit too much effort. I don't claim that my work is superior to kbuild-2.5 or anything. (I still think it may be "good enough", i.e. does solve the current problems - it doesn't add features, though). But I'm dissatified that there never ever was even consideration. When I posted ideas/patches to kbuild-devel, I usually got a response like "this work isn't needed, I developed kbuild-2.5, which will be the solution to all problems in 2.5". I also submitted non-intrusive changes for 2.4, which fixed/simplified things there without breaking anything, but the answer was about the same, "kbuild-2.4 is obsolete, for 2.5 it's irrelevant". Well, 2.4 will be around for some time I guess... When I replied (with technical arguments), I never heard anything back - compare the current thread about just silently dropping mails/patches ;-( That's why I decided to drop out of the kbuild business again. (BTW: note that this was about kbuild-2.5 only - nothing to do with CML2) --Kai From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 16:19:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 16:18:47 -0500 Received: from panic.ohr.gatech.edu ([130.207.47.194]:34743 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 16:18:39 -0500 Date: Fri, 28 Dec 2001 16:16:03 -0500 From: Legacy Fishtank To: linux-kernel@vger.kernel.org Cc: Keith Owens , Larry McVoy , "Eric S. Raymond" , Dave Jones , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228161603.B5397@havoc.gtf.org> In-Reply-To: <18619.1009503350@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kai@tp1.ruhr-uni-bochum.de on Fri, Dec 28, 2001 at 09:56:53PM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org I think one thing to note is that dependencies is that if you are smart about it, dependencies -really- do not even change when your .config changes. What about a system where Linus runs "make deps" -once- before he releases a tarball. This in turn generates dependency information (perhaps not in purely make format) which includes 'ifdef CONFIG_xxx' information embedded within. We know that make can support ifeq CONFIG_xxx for example... Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 16:21:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 16:21:37 -0500 Received: from panic.ohr.gatech.edu ([130.207.47.194]:39095 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 16:21:24 -0500 Date: Fri, 28 Dec 2001 16:19:34 -0500 From: Legacy Fishtank To: "Eric S. Raymond" , Linus Torvalds , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228161934.C5397@havoc.gtf.org> In-Reply-To: <20011228042648.A7943@havoc.gtf.org> <20011228154151.B27313@havoc.gtf.org> <20011228154537.E17774@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011228154537.E17774@thyrsus.com>; from esr@thyrsus.com on Fri, Dec 28, 2001 at 03:45:37PM -0500 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 03:45:37PM -0500, Eric S. Raymond wrote: > Legacy Fishtank : > > For single-file drivers, I like Becker's (correct credit?) system... > > about 10 lines of metadata is embedded in a C comment, and it includes > > the Config.in and Configure.help info. > > I proposed implementing something like this about a year ago (to > replace the nasty centralized knowledge in the MAINTAINERS and CREDITS > files) and was shot down. Note I am specifically NOT talking about MAINTAINERS and CREDITS. -PLEASE- don't obscure my point by mentioning them. Dealing with MAINTAINERS and CREDITS in an automated fashion seems more like pointless masturbation to me. If you want to find out who needs to be CC'd on patches, use your brain like I do. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 16:27:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 16:27:37 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:54746 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 16:27:31 -0500 Date: Fri, 28 Dec 2001 16:12:23 -0500 From: "Eric S. Raymond" To: Legacy Fishtank Cc: Linus Torvalds , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228161223.A19069@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Legacy Fishtank , Linus Torvalds , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228042648.A7943@havoc.gtf.org> <20011228154151.B27313@havoc.gtf.org> <20011228154537.E17774@thyrsus.com> <20011228161934.C5397@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011228161934.C5397@havoc.gtf.org>; from garzik@havoc.gtf.org on Fri, Dec 28, 2001 at 04:19:34PM -0500 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Legacy Fishtank : > Note I am specifically NOT talking about MAINTAINERS and CREDITS. > -PLEASE- don't obscure my point by mentioning them. It's the same problem, Jeff. Same solution, too. -- Eric S. Raymond It will be of little avail to the people, that the laws are made by men of their own choice, if the laws be so voluminous that they cannot be read, or so incoherent that they cannot be understood; if they be repealed or revised before they are promulgated, or undergo such incessant changes that no man, who knows what the law is to-day, can guess what it will be to-morrow. Law is defined to be a rule of action; but how can that be a rule, which is little known, and less fixed? -- James Madison, Federalist Papers 62 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:14:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:14:12 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:41997 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:14:05 -0500 Date: Fri, 28 Dec 2001 14:11:37 -0800 (PST) From: Linus Torvalds To: "Eric S. Raymond" cc: Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , , Subject: Re: State of the new config & build system In-Reply-To: <20011228141211.B15338@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001, Eric S. Raymond wrote: > > I'm not certain what you're objecting to, and I want to understand it. > There are rules that use architecture symbols to suppress things like > bus types. I presume that's not a problem for you, but tell me if it is. It _is_ a problem for me, because I want to do "diffstat" on a patch from a PPC maintainer, and if I see anything non-PPC, loud ringing noises go off in my head. I want that diffstat to say _only_ arch/ppc/... include/asm-ppc/... and nothing else. That way I know that I don't have to worry. In contrast, if it starts talking about Documentation/Configure.help and the main config file, I start worrying. For example, that MATHEMU thing is just ugly. It was perfectly fine in the per-architecture version, now it suddenly has magic dependencies just because different architectures call it different things, and different architectures have different rules on when it's needed. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:09:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:09:14 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:32269 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:09:04 -0500 Date: Fri, 28 Dec 2001 14:06:25 -0800 (PST) From: Linus Torvalds To: Alan Cox cc: Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , , Subject: Re: State of the new config & build system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001, Alan Cox wrote: > > > So if somebody really wants to help this, make scripts that generate > > config files AND Configure.help files from a distributed set. And once you > > do that, you could even imagine creating the old-style config files > > Something like: > > find $TOPDIR -name "*.cf" -exec cat {} \; > Configure.help For old tools.. > or changing the tools to look for > > Documentation/Configure/CONFIG_SMALL_BANANA "small banana"? Freud would go wild. But no. I don't want it under the Documentation directory: I'd much rather have them _together_ with the config file. So the config file format could be something that includes the docs, and you could do something like find . -name '*.cf' -exec grep '^+' {} \; > Configure.help for old tools, and nw tools would just automatically get the docs from the same place they get the config info. And there would _never_ be more than a few entries per config file: you can imagine having a separate config file for PCI 100Mbps ethernet drivers and one for ISA drivers. The current Configure.help is 25k _lines_, and over a megabyte in size. I would never consider that good taste in programming, why should I consider it good in documentation? Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:20:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:20:32 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:53005 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:20:21 -0500 Date: Fri, 28 Dec 2001 14:17:24 -0800 (PST) From: Linus Torvalds To: Legacy Fishtank cc: , Keith Owens , Larry McVoy , "Eric S. Raymond" , Dave Jones , Marcelo Tosatti , Subject: Re: State of the new config & build system In-Reply-To: <20011228161603.B5397@havoc.gtf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001, Legacy Fishtank wrote: > > I think one thing to note is that dependencies is that if you are smart > about it, dependencies -really- do not even change when your .config > changes. Absolutely. I detest "gcc -MD", exactly because it doesn't get this part right. "mkdep.c" gets this _right_. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:25:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:24:52 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:41435 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:24:45 -0500 Date: Fri, 28 Dec 2001 17:08:40 -0500 From: "Eric S. Raymond" To: Linus Torvalds Cc: Alan Cox , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011228170840.A20254@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Linus Torvalds , Alan Cox , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from torvalds@transmeta.com on Fri, Dec 28, 2001 at 02:06:25PM -0800 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds : > So the config file format could be something that includes the docs, and > you could do something like > > find . -name '*.cf' -exec grep '^+' {} \; > Configure.help > > for old tools, and nw tools would just automatically get the docs from the > same place they get the config info. OK. Background, for anyone who doesn't know this: the equivalent of Configure.help in CML2 is the symbols.cml file. It's actually generated fat CML2 installation time from Configure.help. Here's what a sample entry looks like in Configure.help form: Support the foo feature CONFIG_FOO This is a sample help entry. Here's the same entry in CML2 format: FOO "Support the foo feature" text This is a sample help entry. . Now. It would be dead easy to split symbols.cml into bunch of little files and distribute them through the source tree. It would be just as easy to write a script to reassemble Configure.help, but there won't be any reason to do it. Once CML2 goes in, nothing will use Configure.help > The current Configure.help is 25k _lines_, and over a megabyte in size. I > would never consider that good taste in programming, why should I consider > it good in documentation? Um...because the cases aren't parallel? What makes megabyte-large blocks of code bad is that they tend to be tangled messes with unmaintainable reference and control structures. Configure.help isn't; the entries are atoms that don't interact with each other. -- Eric S. Raymond We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time. -- T.S. Eliot From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:30:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:30:13 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:6670 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:30:05 -0500 Date: Fri, 28 Dec 2001 14:27:37 -0800 (PST) From: Linus Torvalds To: "Eric S. Raymond" cc: Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , , Subject: Re: State of the new config & build system In-Reply-To: <20011228161223.A19069@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001, Eric S. Raymond wrote: > Legacy Fishtank : > > Note I am specifically NOT talking about MAINTAINERS and CREDITS. > > -PLEASE- don't obscure my point by mentioning them. > > It's the same problem, Jeff. Same solution, too. It's not. We already have pre-file credits information - people can put stuff in there for their own (C) messages etc. The MAINTAINERS file is a much higher-level thing which is there to be human-readable. Note that I do _not_ want to mess up source files with magic comments. I absolutely detest those. They only detract from the real job of coding, and do not make anybody happier. We have a hierarchical filesystem. Most drivers already have driver.c driver.h (in fact _very_ few drivers are single-file) and some have a subdirectory of their own. So why not just have driver.conf and be done with it. No point in messing up the C file with stuff that doesn't add any information to either the programmer _or_ the compiler. Then you can make the config file _truly_ readable, and make the format something like define tristate CONFIG_SCSI_AIC7XXX: Adaptec AIC7xxx support This driver supports all of Adaptec's PCI based SCSI controllers (not the hardware RAID controllers though) as well as the aic7770 based EISA and VLB SCSI controllers (the 274x and 284x series). This is an Adaptec sponsored driver written by Justin Gibbs. It is intended to replace the previous aic7xxx driver maintained by Doug Ledford since Doug is no longer maintaining that driver. depends on CONFIG_SCSI depends on CONFIG_PCI depends on ... define integer CONFIG_AIC7XXX_CMDS_PER_DEVICE: Maximum number of TCQ commands per device depends on CONFIG_SCSI_AIC7XXX default value 253 define integer CONFIG_AIC7XXX_RESET_DELAY_MS: Initial bus reset delay in milli-seconds depends on CONFIG_SCSI_AIC7XXX default value 15000 .... and it's readable and probably trivially parseable into both the existing format (ie some "find . -name '*.conf'" plus sed-scripts) and into cml2 or whatever. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:30:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:29:52 -0500 Received: from bitmover.com ([192.132.92.2]:10404 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:29:37 -0500 Date: Fri, 28 Dec 2001 14:29:32 -0800 From: Larry McVoy To: "Eric S. Raymond" , Linus Torvalds , Alan Cox , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011228142932.G3727@work.bitmover.com> Mail-Followup-To: "Eric S. Raymond" , Linus Torvalds , Alan Cox , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228170840.A20254@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20011228170840.A20254@thyrsus.com>; from esr@thyrsus.com on Fri, Dec 28, 2001 at 05:08:40PM -0500 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 05:08:40PM -0500, Eric S. Raymond wrote: > What makes megabyte-large blocks of code bad is that they tend to be > tangled messes with unmaintainable reference and control structures. > Configure.help isn't; the entries are atoms that don't interact with > each other. Doesn't this statement miss the point that the configure stuff belongs with the associated source, for many reasons? Reasons being stuff like Linus' desire to see PPC stuff only under the PPC directories, stuff like the desire to have the config stuff as part of the source. The very fact that they are atoms and don't interact with each seems to scream that they should be located next to, or in, the stuff with which they do interact. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:32:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:32:12 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:10766 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:32:04 -0500 Date: Fri, 28 Dec 2001 14:29:44 -0800 (PST) From: Linus Torvalds To: "Eric S. Raymond" cc: Alan Cox , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , , Subject: Re: [kbuild-devel] Re: State of the new config & build system In-Reply-To: <20011228170840.A20254@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001, Eric S. Raymond wrote: > > OK. Background, for anyone who doesn't know this: the equivalent of > Configure.help in CML2 is the symbols.cml file. It's actually generated > fat CML2 installation time from Configure.help. Oh, crap, _another_ magic global file. Eric, this is the _wrong_approach_. I want /local/ files, not global ones. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:47:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:47:20 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:48091 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:47:01 -0500 Date: Fri, 28 Dec 2001 17:31:51 -0500 From: "Eric S. Raymond" To: Linus Torvalds Cc: Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228173151.B20254@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228141211.B15338@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from torvalds@transmeta.com on Fri, Dec 28, 2001 at 02:11:37PM -0800 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds : > On Fri, 28 Dec 2001, Eric S. Raymond wrote: > > I'm not certain what you're objecting to, and I want to understand it. > > There are rules that use architecture symbols to suppress things like > > bus types. I presume that's not a problem for you, but tell me if it is. > > It _is_ a problem for me, because I want to do "diffstat" on a patch from > a PPC maintainer, and if I see anything non-PPC, loud ringing > noises go off in my head. I want that diffstat to say _only_ > > arch/ppc/... > include/asm-ppc/... > > and nothing else. That way I know that I don't have to worry. Perhaps we're talking past each other. I don't understand your objection yet, and I want to so I can design (or redesign) to meet it. When I talk about "rules that use architecture symbols to suppress things like bus types" I have in mind things like this: unless X86 suppress dependent MCA EISA unless MIPS32 suppress dependent TC unless (PCI and (X86 or SUPERH)) suppress pci_access unless (ISA or PCI) suppress dependent IDE unless PCI suppress dependent USB HOTPLUG_PCI unless (X86 or ALPHA or MIPS32 or PPC) suppress usb unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent IEEE1394 unless (M68K or ALL_PPC) suppress MACINTOSH_DRIVERS unless SPARC suppress dependent FC4 unless ARCH_S390==n suppress buses It seems to me *extremely* unlikely that a typical patch from a PPC maintainer would mess with any of these! They're rules that are likely to be written once at the time a new port is added to the tree and seldom or ever changed afterwards. Thus I really don't think you have to worry about spurious spikes in your diffstat. The root rules.cml file will not change very often -- I know this is true, because I can look at the RCS history since I broke it out in response to your request at the Kernel Summit and *see* that changes have been few and sparse. > In contrast, if it starts talking about Documentation/Configure.help and > the main config file, I start worrying. Rightly so in the latter case. Configure.help patches shouldn't worry you, I don't think. It's not like they can actually break anything. > For example, that MATHEMU thing is just ugly. It was perfectly fine in the > per-architecture version, now it suddenly has magic dependencies just > because different architectures call it different things, and different > architectures have different rules on when it's needed. It sounds to me like you're agreeing that it *shouldn't* be called different things, and thus with my goal of cleaning this mess up the rest of the way. Yes? No? Guidance, please. I am, as ever, willing to meet your concerns. But I have to understand clearly what they are in order to do that. -- Eric S. Raymond "...The Bill of Rights is a literal and absolute document. The First Amendment doesn't say you have a right to speak out unless the government has a 'compelling interest' in censoring the Internet. The Second Amendment doesn't say you have the right to keep and bear arms until some madman plants a bomb. The Fourth Amendment doesn't say you have the right to be secure from search and seizure unless some FBI agent thinks you fit the profile of a terrorist. The government has no right to interfere with any of these freedoms under any circumstances." -- Harry Browne, 1996 USA presidential candidate, Libertarian Party From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:42:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:42:38 -0500 Received: from [195.63.194.11] ([195.63.194.11]:45835 "EHLO mail.stock-world.de") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:42:32 -0500 Message-ID: <3C2CF2A8.9010406@evision-ventures.com> Date: Fri, 28 Dec 2001 23:31:04 +0100 From: Martin Dalecki User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us, pl MIME-Version: 1.0 To: Larry McVoy CC: Keith Owens , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: <20011227173739.U25698@work.bitmover.com> <18754.1009503708@ocs3.intra.ocs.com.au> <20011227174723.V25698@work.bitmover.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Larry McVoy wrote: >On Fri, Dec 28, 2001 at 12:41:48PM +1100, Keith Owens wrote: > >>On Thu, 27 Dec 2001 17:37:39 -0800, >>Larry McVoy wrote: >> >>>A couple of questions: >>> >>>a) will 2.5 be as fast as the current system? Faster? >>> >>At the moment kbuild 2.5 ranges from 10% faster on small builds to 100% >>slower on a full kernel build. >> > >I don't understand why it would be slower. > Thank's go to basically to python and other excessfull overengineering there. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:51:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:51:28 -0500 Received: from bitmover.com ([192.132.92.2]:23716 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:51:17 -0500 Date: Fri, 28 Dec 2001 14:51:13 -0800 From: Larry McVoy To: Kai Germaschewski Cc: Keith Owens , Larry McVoy , "Eric S. Raymond" , Dave Jones , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228145113.I3727@work.bitmover.com> Mail-Followup-To: Kai Germaschewski , Keith Owens , Larry McVoy , "Eric S. Raymond" , Dave Jones , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <18619.1009503350@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from kai@tp1.ruhr-uni-bochum.de on Fri, Dec 28, 2001 at 09:56:53PM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 09:56:53PM +0100, Kai Germaschewski wrote: > A couple of months ago, I came up with an alternative to kbuild 2.5. It > doesn't try to have all the features kbuild 2.5 has, but solves the major > problems with kbuild 2.4. So has anyone looked at this? Is this a viable choice? I've heard nothing since Kai posted this. Keith? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 17:58:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 17:58:49 -0500 Received: from [195.63.194.11] ([195.63.194.11]:53515 "EHLO mail.stock-world.de") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 17:58:36 -0500 Message-ID: <3C2CF688.5010503@evision-ventures.com> Date: Fri, 28 Dec 2001 23:47:36 +0100 From: Martin Dalecki User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us, pl MIME-Version: 1.0 To: Linus Torvalds CC: Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds wrote: >[ Btw, Jeff, any reason why you changed your name to "Legacy Fishtank"? It > took a few mails before I noticed that it also said "garzik" in the > fine print;] > >One thing that this big flame-war has brought up is that different people >like different things. There may be a simpler solution to this: have the >core dependency files generated from some other file format. > >My pet peeve is "centralized knowledge". I absolutely detested the first >versions of cml2 for having a single config file, and quite frankly I >don't think Eric has even _yet_ separated things out enough - why does the >main "rules.cml" file have architecture-specific info, for example? > >That's a big step backwards as far as I'm concerned - we didn't use to >have those stupid global files, and each architecture could do it's own >config rules. Eric never got the point that to me, modularity is _the_ >most important thing for maintenance. > >Something I also asked for the config system at least a year ago was to >have Configure.help split up. Never happened. It's still one large ugly >file. Driver or architecture maintainers still can't just change _their_ >small fragment, they have to touch a global file that they don't "own". > >So if somebody really wants to help this, make scripts that generate >config files AND Configure.help files from a distributed set. And once you >do that, you could even imagine creating the old-style config files >(without the automatic checking and losing some information) from the >information. > If you go thus far... then I think, that the Configure.help stuff should be embedded inside the driver source code itself. Like for example the postfix MTA code is embedding whole *man* pages there. And *man* pages would be anyway a more appriopriate and classical place where the current Configure.help information should be. Just lift the code over from there (The extraction is even proper awk insead of some perl crap...) and be nearly done. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 18:03:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 18:03:08 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:20749 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 18:02:59 -0500 Subject: Re: State of the new config & build system To: esr@thyrsus.com Date: Fri, 28 Dec 2001 23:13:00 +0000 (GMT) Cc: garzik@havoc.gtf.org (Legacy Fishtank), torvalds@transmeta.com (Linus Torvalds), davej@suse.de (Dave Jones), esr@snark.thyrsus.com (Eric S. Raymond), marcelo@conectiva.com.br (Marcelo Tosatti), linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228154537.E17774@thyrsus.com> from "Eric S. Raymond" at Dec 28, 2001 03:45:37 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > I'd be happy to take another swing at this problem once the kbuild-2.5/CML2 > transition is done. But I don't think we should let it block us from > having the good results we can get from that change. It would certainly fit nicely with the existing metadata. We already rip out code comments via kernel-doc, and extending it to rip out - Help text - Web site - Version information - Man page for the driver - Module options etc, shouldn't be too challenging. Ok so kernel-doc is in perl and ugly perl but if someone hates it enough to rewrite it in python thats a win too 8) Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 18:10:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 18:10:38 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:32269 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 18:10:32 -0500 Subject: Re: State of the new config & build system To: viro@math.psu.edu (Alexander Viro) Date: Fri, 28 Dec 2001 23:20:01 +0000 (GMT) Cc: esr@thyrsus.com (Eric S. Raymond), torvalds@transmeta.com (Linus Torvalds), garzik@havoc.gtf.org (Legacy Fishtank), davej@suse.de (Dave Jones), esr@snark.thyrsus.com (Eric S. Raymond), marcelo@conectiva.com.br (Marcelo Tosatti), linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: from "Alexander Viro" at Dec 28, 2001 03:26:32 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > Frankly, I find it very amusing that advocates of i18n efforts tend to > be either British or USAnians. Folks, get real - your languages are > too close to show where the problems are. I can see how doing that > gives you a warm fuzzy feeling, but could you please listen to those > of us who have to deal with the resulting mess for real? The biggest advocates I see are from the Middle-East and Japan. We already have people providing translations for Configure.help in several languages. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 18:06:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 18:06:08 -0500 Received: from lacrosse.corp.redhat.com ([12.107.208.154]:42098 "EHLO lacrosse.corp.redhat.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 18:06:03 -0500 Date: Fri, 28 Dec 2001 18:05:57 -0500 From: Benjamin LaHaise To: Linus Torvalds Cc: "Eric S. Raymond" , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228180557.B8216@redhat.com> In-Reply-To: <20011228161223.A19069@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from torvalds@transmeta.com on Fri, Dec 28, 2001 at 02:27:37PM -0800 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 02:27:37PM -0800, Linus Torvalds wrote: > and it's readable and probably trivially parseable into both the existing > format (ie some "find . -name '*.conf'" plus sed-scripts) and into cml2 or > whatever. It's even doable within the .c file (and preferable for small drivers). Something like: /* mydriver.c .... header blah blah */ config_requires(CONFIG_INET); config_option(CONFIG_MY_FAST_CHIP, "Help info for this"); which gets picked out of the .c files during depend phase, and nullified during compile by means of -Iconfig_system.h would even let us get rid of Makefiles for drivers. Wouldn't being able to just drop a .c file (or a bunch of .c files) into the tree in the right place be great? Eliminating makefiles means eliminating more conflicts, which might mean more time to respond to other issues... -ben -- Fish. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 18:13:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 18:12:59 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:22287 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 18:12:48 -0500 Date: Fri, 28 Dec 2001 15:10:26 -0800 (PST) From: Linus Torvalds To: Alan Cox cc: , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , , Subject: Re: State of the new config & build system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001, Alan Cox wrote: > > It would certainly fit nicely with the existing metadata. We already rip out > code comments via kernel-doc, and extending it to rip out > > - Help text > - Web site ... No no no. The comments can at least be helpful to programmers, whether ripped out or not. Extra stuff is not helpful to anybody, and is just really irritating. I personally despise source trees that start out with one page of copyright statement crap, it just detracts from the real _point_ of the .c file, which is to contain C code. Making it a comment requirement is - stupid: we have a filesystem, guys - slow: we don't need to parse every C file we encounter when we can just open another file based on filename - nonsensical: many config options are _not_ limited to one C file - hard to parse and read: why limit ourself to C comments, when just keeping the thing logically separated means that we don't have to. Having per-function comment blocks, in contrast, makes sense to have inline: - you read the comment when you read the function - you might even update the comment when you update the function - you have a reasonable 1:1 relationship. _None_ of those are sensible for config file entries. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 18:18:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 18:18:51 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:58331 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 18:18:28 -0500 Date: Fri, 28 Dec 2001 18:02:12 -0500 From: "Eric S. Raymond" To: Martin Dalecki Cc: Larry McVoy , Keith Owens , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228180212.E20254@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Martin Dalecki , Larry McVoy , Keith Owens , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011227173739.U25698@work.bitmover.com> <18754.1009503708@ocs3.intra.ocs.com.au> <20011227174723.V25698@work.bitmover.com> <3C2CF2A8.9010406@evision-ventures.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C2CF2A8.9010406@evision-ventures.com>; from dalecki@evision-ventures.com on Fri, Dec 28, 2001 at 11:31:04PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Martin Dalecki : > >>At the moment kbuild 2.5 ranges from 10% faster on small builds to 100% > >>slower on a full kernel build. > > > >I don't understand why it would be slower. > > > Thank's go to basically to python and other excessfull overengineering > there. Bzzzt! Thank you for playing. kbuild-2.5 doesn't use Python. -- Eric S. Raymond The possession of arms by the people is the ultimate warrant that government governs only with the consent of the governed. -- Jeff Snyder From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 18:15:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 18:15:00 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:55003 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 18:14:43 -0500 Date: Fri, 28 Dec 2001 17:58:32 -0500 From: "Eric S. Raymond" To: Linus Torvalds Cc: Alan Cox , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011228175832.C20254@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Linus Torvalds , Alan Cox , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228170840.A20254@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from torvalds@transmeta.com on Fri, Dec 28, 2001 at 02:29:44PM -0800 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds : > Eric, this is the _wrong_approach_. I want /local/ files, not global ones. I hear you. There are some problems with that, however. First: where should the prompt-string definitions for capability symbols that occur in multiple port trees live? (This is an important question. Right now, most options are low-level and platform-specific, which makes it easy to decide what directory their symbol declaration(s) should live in. But that's not good; there are lots of excellent reasons we want there to be *more* cross-platform capability symbols rather than fewer. So the percentage of "roving" symbols without an obvious home is likely to go up over time.) Second: Forward references, and references across the tree, mean that there is a class of symbols that have theoretically natural home directories but which would have to be declared elsewhere in order to be defined at the point of first reference. (A potential solution to this would be to improve the CML2 compiler's handling of forward references.) Third: I could hack my installer to break Configure.help up into a bunch of little component CML files distributed through the tree... but Configure.help doesn't currently contain any markup that says where to direct each entry to. (The logical time to split up symbols.cml would be immediately after CML2 goes into the tree, because at that point Configure.help won't be an issue any more.) Fourth: There's still the localization issue. If it's your ukase that this is not an important problem, then I'll accept that -- but I haven't heard you say that yet, so I'm not sure you've considered it enough. So, I can and will put this in the transition plan if that's what you direct. But you need to be aware that it's not a snap-of-the-fingers change, and not something best done before CML1 goes away. -- Eric S. Raymond "As to the species of exercise, I advise the gun. While this gives [only] moderate exercise to the body, it gives boldness, enterprise, and independence to the mind. Games played with the ball and others of that nature, are too violent for the body and stamp no character on the mind. Let your gun, therefore, be the constant companion to your walks." -- Thomas Jefferson, writing to his teenaged nephew. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 18:26:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 18:26:00 -0500 Received: from mail012.syd.optusnet.com.au ([203.2.75.172]:18857 "EHLO mail012.syd.optusnet.com.au") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 18:25:42 -0500 Date: Sat, 29 Dec 2001 10:25:38 +1100 Mime-Version: 1.0 (Apple Message framework v480) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: State of the new config & build system From: Stewart Smith To: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Content-Transfer-Encoding: 7bit Message-Id: <33D0FE78-FBEA-11D5-880A-00039350C45A@softhome.net> X-Mailer: Apple Mail (2.480) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org dammit, didn't hit "reply all" grr.... On Saturday, December 29, 2001, at 05:02 AM, Linus Torvalds wrote: > My pet peeve is "centralized knowledge". I absolutely detested the first > versions of cml2 for having a single config file, and quite frankly I > don't think Eric has even _yet_ separated things out enough - why does > the > main "rules.cml" file have architecture-specific info, for example? agreed - it's something that really irritates me too. As Linux is running on so many different architectures (some of which are purely virtual, such as Usermode Linux and my whacky idea of running it ontop of MacOS X) so it seems that keeping all the options for architectures separate would make a lot of sense. I've never seen a cross-platform binary kernel (although have had scary dreams of one) > So if somebody really wants to help this, make scripts that generate > config files AND Configure.help files from a distributed set. And once > you > do that, you could even imagine creating the old-style config files > (without the automatic checking and losing some information) from the > information. This shouldn't be too hard should it? In each module directory have a config and Configure.help file, then just find . |grep config and then cat all the files together. If I have some spare time today I'll see if I can hack something up.... :) ------------------------------ Stewart Smith stewart@softhome.net Ph: +61 4 3884 4332 ICQ: 6734154 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 18:20:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 18:20:31 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:60123 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 18:20:18 -0500 Date: Fri, 28 Dec 2001 18:04:28 -0500 From: "Eric S. Raymond" To: Alan Cox Cc: Legacy Fishtank , Linus Torvalds , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228180428.F20254@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , Legacy Fishtank , Linus Torvalds , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228154537.E17774@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Dec 28, 2001 at 11:13:00PM +0000 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > > I'd be happy to take another swing at this problem once the kbuild-2.5/CML2 > > transition is done. But I don't think we should let it block us from > > having the good results we can get from that change. > > It would certainly fit nicely with the existing metadata. We already rip out > code comments via kernel-doc, and extending it to rip out > > - Help text > - Web site > - Version information > - Man page for the driver > - Module options > > etc, shouldn't be too challenging. Ok so kernel-doc is in perl and ugly perl > but if someone hates it enough to rewrite it in python thats a win too 8) I've been thinking about doing that very thing anyway. Part of my master plan to reduce the tree's external dependencies. -- Eric S. Raymond I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 18:25:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 18:25:22 -0500 Received: from [195.63.194.11] ([195.63.194.11]:65035 "EHLO mail.stock-world.de") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 18:23:27 -0500 Message-ID: <3C2CFC42.7000401@evision-ventures.com> Date: Sat, 29 Dec 2001 00:12:02 +0100 From: Martin Dalecki User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us, pl MIME-Version: 1.0 To: Linus Torvalds CC: Alan Cox , esr@thyrsus.com, Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds wrote: >On Fri, 28 Dec 2001, Alan Cox wrote: > >>It would certainly fit nicely with the existing metadata. We already rip out >>code comments via kernel-doc, and extending it to rip out >> >> - Help text >> - Web site >> >... > >No no no. > >The comments can at least be helpful to programmers, whether ripped out or >not. > >Extra stuff is not helpful to anybody, and is just really irritating. I >personally despise source trees that start out with one page of copyright >statement crap, it just detracts from the real _point_ of the .c file, >which is to contain C code. Making it a comment requirement is > > - stupid: > we have a filesystem, guys > Not quite... It is making moving patches through e-mail around easier... > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 19:18:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 19:18:24 -0500 Received: from d-dialin-2776.addcom.de ([213.61.81.144]:38126 "EHLO localhost.localdomain") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 19:18:19 -0500 Date: Sat, 29 Dec 2001 00:44:06 +0100 (CET) From: Kai Germaschewski X-X-Sender: To: Linus Torvalds cc: Legacy Fishtank , , Keith Owens , Larry McVoy , "Eric S. Raymond" , Dave Jones , Marcelo Tosatti , Subject: Re: State of the new config & build system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001, Linus Torvalds wrote: > On Fri, 28 Dec 2001, Legacy Fishtank wrote: > > > > I think one thing to note is that dependencies is that if you are smart > > about it, dependencies -really- do not even change when your .config > > changes. > > Absolutely. I detest "gcc -MD", exactly because it doesn't get this part > right. "mkdep.c" gets this _right_. Well, -MD gets this right. The dependencies it generates will cause a recompile when necessary. Unfortunately, though, it's too good, because the dependency on include/linux/autoconf.h will cause lots of unnecessary recompiles. But yes, it seems possible to replace the -MD dependency file, which depends on a specific config, with a generic dependency file, which knows about our #ifdef CONFIG_XXX and translates them to the corresponding ifeq(CONFIG_,) Makefile syntax. It'd make an interesting project, but it effectively means re-implementing a C preprocessor. I don't think you can blame gcc -MD for not knowing about the kernel's CONFIG_ system, though ;-) From --- #ifdef CONFIG_XXX #include #endif #ifdef CONFIG_YYY const int nr = 10; #else const int nr = 100; #endif --- you'd have to generate --- ifeq(CONFIG_XXX,y) DEPS += include/linux/xxx.h endif DEPS += include/config/yyy --- i.e. the include/config trick has to stay any way. I don't think the above is necessary, though, the following does work pretty good (I did it this way, inspired by mec, and I think kbuild-2.5 does it similarly): Generate dependencies for a .o file when compiling it. [ Doing make dep in advance is unnessary. Actually, it's pretty stupid to generate dependencies for *all* possible object files which you are never going to compile (think arch/*). If you don't have the object yet, you don't need to know the dependencies, dependencies only make sense for recompiles. It's also cheaper to generate dependencies during the compile, as you need to read the file anyway. Also, dependencies on generated files cannot be found correctly until these files have been generated. ] The generated dependencies will always include linux/autoconf.h, which is correct, but will cause too many recompiles. So, replace linux/autoconf.h with linux/config/xxx, where xxx are all the config options which appear in all of the files used to build the object file (which is what -MD gave you). The result is still dependencies which are 100% correct. It's that simple. The object file gcc generates depends on the command line and all the files it reads during the compile. Why make it more complex? --Kai From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 19:50:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 19:50:36 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:22031 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 19:50:15 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Larry McVoy Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 12:01:04 -0800." <20011228120104.B4077@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Dec 2001 11:50:02 +1100 Message-ID: <7390.1009587002@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org cc: list trimmed. On Fri, 28 Dec 2001 12:01:04 -0800, Larry McVoy wrote: >On Fri, Dec 28, 2001 at 08:42:44PM +1100, Keith Owens wrote: >> "All" I need to do is have one server process that reads the big list >> once and the other client processes talk to the server. Much less data >> involved means faster conversion from absolute to standardized names. > >Actually, if you use the mdbm code, you can have a server process which >reads the data, stashes it in the db, touchs ./i_am_done, and exits. >"client" processes do a > > while (!exists("i_am_done")) usleep(100000); > m = mdbm_open("db", O_RDONLY, 0, 0); > val = mdbm_fetch_str(m, "key"); > etc. > >No sockets, no back and forth, runs at mmap speed. > >If you tell me what the data looks like that needs to be in the DB, i.e., >how to get it, I'll code you up the "server" side. I also want updates from the dependency back end code, to remove the phase 5 processing. The "extract dependency" code runs after each compile step so there can be multiple updates running in parallel. My gut feeling is that it will be faster to have one database server and all the back ends talk to that server. Otherwise each compile will have overhead for lock, open, mmap, update, close, write back, unlock. A single threading server removes the need for lock/unlock and can sync the data to disk after n compiles instead of being forced to do it after every compile. If your experience says that doing updates from each compile step without a server process would not be too slow, let me know. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 19:56:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 19:56:16 -0500 Received: from bitmover.com ([192.132.92.2]:7589 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 19:56:03 -0500 Date: Fri, 28 Dec 2001 16:55:59 -0800 From: Larry McVoy To: Keith Owens Cc: Larry McVoy , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228165559.N3727@work.bitmover.com> Mail-Followup-To: Keith Owens , Larry McVoy , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228120104.B4077@work.bitmover.com> <7390.1009587002@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <7390.1009587002@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Sat, Dec 29, 2001 at 11:50:02AM +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > I also want updates from the dependency back end code, to remove the > phase 5 processing. The "extract dependency" code runs after each > compile step so there can be multiple updates running in parallel. My > gut feeling is that it will be faster to have one database server and > all the back ends talk to that server. Otherwise each compile will > have overhead for lock, open, mmap, update, close, write back, unlock. > A single threading server removes the need for lock/unlock and can sync > the data to disk after n compiles instead of being forced to do it > after every compile. > > If your experience says that doing updates from each compile step > without a server process would not be too slow, let me know. You certainly don't need a server process. And as was pointed out earlier, it's nice not to have them, then you don't have to worry about them still being there. I can write you up a multi writer version using in file locks (which work over NFS, we had do that for BK and I'm pretty sure it is platform independent, I can't break it). We have to do this sort of multi reader/writer crud in BK all the time and have lots of experience with locking, breaking locks, waiting, NFS, etc. Much more experience than we ever wanted :-) You don't need to sync to disk at all, let the data sit in memory, that's why mmap is cool. Give me a spec for what you want, I'll crank out some code. Maybe I'll finally actually be useful to the kernel after all these years... -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 19:59:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 19:59:28 -0500 Received: from panic.ohr.gatech.edu ([130.207.47.194]:28348 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 19:59:15 -0500 Date: Fri, 28 Dec 2001 19:59:14 -0500 From: Legacy Fishtank To: Benjamin LaHaise Cc: Linus Torvalds , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228195914.A14127@havoc.gtf.org> In-Reply-To: <20011228161223.A19069@thyrsus.com> <20011228180557.B8216@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011228180557.B8216@redhat.com>; from bcrl@redhat.com on Fri, Dec 28, 2001 at 06:05:57PM -0500 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 06:05:57PM -0500, Benjamin LaHaise wrote: > On Fri, Dec 28, 2001 at 02:27:37PM -0800, Linus Torvalds wrote: > > and it's readable and probably trivially parseable into both the existing > > format (ie some "find . -name '*.conf'" plus sed-scripts) and into cml2 or > > whatever. > > It's even doable within the .c file (and preferable for small drivers). > Something like: > > /* mydriver.c .... header blah blah */ > config_requires(CONFIG_INET); > config_option(CONFIG_MY_FAST_CHIP, "Help info for this"); If Linus is willing to buy into "driver.conf" there is no need to stuff things into the source. [my previous post made the mistaken assumption that Linus would not like an additional metadata file like driver.conf] A per-driver metadata file is IMHO clearly the preferred solution. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 20:27:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 20:27:14 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:8976 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 20:27:04 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Legacy Fishtank Cc: linux-kernel@vger.kernel.org, Larry McVoy , "Eric S. Raymond" , Dave Jones , Linus Torvalds , Marcelo Tosatti , kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 16:16:03 CDT." <20011228161603.B5397@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Dec 2001 12:26:49 +1100 Message-ID: <7850.1009589209@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001 16:16:03 -0500, Legacy Fishtank wrote: >I think one thing to note is that dependencies is that if you are smart >about it, dependencies -really- do not even change when your .config >changes. > >What about a system where Linus runs "make deps" -once- before he >releases a tarball. This in turn generates dependency information >(perhaps not in purely make format) which includes 'ifdef CONFIG_xxx' >information embedded within. We know that make can support ifeq >CONFIG_xxx for example... Then people apply patches and break. Please read the list of mkdep bugs before suggesting partial fixes. http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2, makefile-2.5_make_dep.html. I want a system that fixes _all_ the bugs, not just some of them. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 20:28:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 20:27:54 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:12560 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 20:27:38 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Linus Torvalds Cc: Legacy Fishtank , linux-kernel@vger.kernel.org, Larry McVoy , "Eric S. Raymond" , Dave Jones , Marcelo Tosatti , kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 14:17:24 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Dec 2001 12:27:24 +1100 Message-ID: <7861.1009589244@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001 14:17:24 -0800 (PST), Linus Torvalds wrote: > >On Fri, 28 Dec 2001, Legacy Fishtank wrote: >> >> I think one thing to note is that dependencies is that if you are smart >> about it, dependencies -really- do not even change when your .config >> changes. > >Absolutely. I detest "gcc -MD", exactly because it doesn't get this part >right. "mkdep.c" gets this _right_. Sorry, it does not. Everybody is attacking little bits of the dependency problem, any solution that does not fix _all_ 9 problems in http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2, makefile-2.5_make_dep.html is not a complete fix. Yes, some of the problems with mkdep can be fixed in the current design but there is one problem that is inherently unfixable. make dep is a manual process so it relies on users knowing when they have to rerun make dep AND THEY DON'T DO IT! Please do not say "I always run make dep" after a change, I guarantee that you are the exception. Users apply patches and do not run make dep, then wonder why their kernel is broken. Dependencies _do_ change when your .config changes, the list of files that are included varies. gcc -MD gets this exactly right, gcc knows which files it read. mkdep does an incorrect approximation, see tyhe bug list in makefile-2.5_make_dep.html. The errors in mkdep were acceptable as long as only kernel hackers built their own kernels, they could be relied upon to manually run commands when necessary. The target population has changed, more and more beginners are building kernels and too many are getting it wrong. I am aiming at the entire population, not that small subset who have been building kernels since the year dot. Any build system that silently fails when users forget to run a command is a broken system. kbuild 2.5 fixes _all_ 9 problems with mkdep, it also positions us for correct modversion handling. kbuild 2.4 is faster, inaccurate and manual, kbuild 2.5 is slower, accurate and totally automatic. I know how to speed up 2.5. What I don't have is time to rewrite the code for speed, I am too busy tracking kernel changes because kbuild 2.5 is not in the kernel yet. Linus, you have a choice between a known broken build system and a clean and reliable system, which is slightly slower in mark 1. Please add kbuild 2.5 to the kernel, then I will have time to rewrite the core programs for speed. Mark 2 of the core code will be significantly faster. ps. I don't want mail discussing individual bug fixes to mkdep. Code that does not fix _all_ 9 bugs listed in makefile-2.5_make_dep.html is pointless. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 20:44:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 20:43:46 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:36622 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 20:43:38 -0500 Subject: Re: State of the new config & build system To: kaos@ocs.com.au (Keith Owens) Date: Sat, 29 Dec 2001 01:53:17 +0000 (GMT) Cc: torvalds@transmeta.com (Linus Torvalds), garzik@havoc.gtf.org (Legacy Fishtank), linux-kernel@vger.kernel.org, lm@bitmover.com (Larry McVoy), esr@thyrsus.com (Eric S. Raymond), davej@suse.de (Dave Jones), marcelo@conectiva.com.br (Marcelo Tosatti), kbuild-devel@lists.sourceforge.net In-Reply-To: <7861.1009589244@ocs3.intra.ocs.com.au> from "Keith Owens" at Dec 29, 2001 12:27:24 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > dependency problem, any solution that does not fix _all_ 9 problems in > http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2, > makefile-2.5_make_dep.html is not a complete fix. All well and good but "takes 100% longer" is number 10 on that list which you missed off, and the same argument holds for that. > but there is one problem that is inherently unfixable. make dep is a > manual process so it relies on users knowing when they have to rerun > make dep AND THEY DON'T DO IT! Please do not say "I always run make So automate running make dep. > Linus, you have a choice between a known broken build system and a So broken its worked for say 5 years without major problem > ps. I don't want mail discussing individual bug fixes to mkdep. Code > that does not fix _all_ 9 bugs listed in makefile-2.5_make_dep.html > is pointless. And bug number 10 you didnt mention From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 20:44:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 20:44:26 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:22800 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 20:44:13 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alan Cox Cc: wingel@hog.ctrl-c.liu.se (Christer Weinigel), linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 17:39:08 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Dec 2001 12:44:00 +1100 Message-ID: <7974.1009590240@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001 17:39:08 +0000 (GMT), Alan Cox wrote: >> * make dep is only run once >> >> Personally, I don't see this as a big problem. Just tell people to > >I run make dep whenever I change config. Guess what - one cmp and I can >automate that as part of make. If the .config doesnt match the >.configwhendep then its time to make dep again Don't forget that any change that affects a file's #include list (including patches) requires you to run make dep. make dep does not handle generated files at all, change the code that generates a file and the file is regenerated but make dep did not pick up the file the first time so kbuild 2.4 does not detect the change. Another make dep will fix that of course. So now we have Run make dep after - A change to .config. Any source change, it might have changed the #include list. Any source or command line change that affects generated files. How do you automate that? You end up saying that you always run make dep. >> That dependencies are absolute is also not a thing that has bothered me >> too much, it's always possible to run "make dep" after moving a tree, >> on the other hand, I don't use NFS a lot anymore, so I can see it being >> a problem in other environments. > >sed works too, as do symlinks For people who know what they are doing, not for the larger population that are struggling with the kernel build process. kbuild 2.5 is designed to work accurately and automatically for everyone, from the high druids of the kernel down to the lowliest newbie. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 21:01:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 21:01:09 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:44814 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 28 Dec 2001 21:00:54 -0500 Subject: Re: State of the new config & build system To: kaos@ocs.com.au (Keith Owens) Date: Sat, 29 Dec 2001 02:10:43 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), torvalds@transmeta.com (Linus Torvalds), garzik@havoc.gtf.org (Legacy Fishtank), linux-kernel@vger.kernel.org, lm@bitmover.com (Larry McVoy), esr@thyrsus.com (Eric S. Raymond), davej@suse.de (Dave Jones), marcelo@conectiva.com.br (Marcelo Tosatti), kbuild-devel@lists.sourceforge.net In-Reply-To: <8178.1009591067@ocs3.intra.ocs.com.au> from "Keith Owens" at Dec 29, 2001 12:57:47 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > Unlike bio, kbuild 2.5 works, it just needs to be a bit faster. Put > kbuild 2.5 in the kernel and I will have a faster version within 2 > weeks. Ok. I was assuming from what you had said that we were talking about months before it got up to a sane speed. If its 2 weeks then I have absolutely no problems with that. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 20:58:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 20:58:10 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:27152 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 20:58:04 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alan Cox Cc: torvalds@transmeta.com (Linus Torvalds), garzik@havoc.gtf.org (Legacy Fishtank), linux-kernel@vger.kernel.org, lm@bitmover.com (Larry McVoy), esr@thyrsus.com (Eric S. Raymond), davej@suse.de (Dave Jones), marcelo@conectiva.com.br (Marcelo Tosatti), kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Sat, 29 Dec 2001 01:53:17 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Dec 2001 12:57:47 +1100 Message-ID: <8178.1009591067@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 29 Dec 2001 01:53:17 +0000 (GMT), Alan Cox wrote: >> dependency problem, any solution that does not fix _all_ 9 problems in >> http://prdownloads.sourceforge.net/kbuild/kbuild-2.5-history.tar.bz2, >> makefile-2.5_make_dep.html is not a complete fix. > >All well and good but "takes 100% longer" is number 10 on that list which >you missed off, and the same argument holds for that. You are missing the point Alan. * The makefile rules are correct now. * The build is correct now. * kbuild 2.5 is faster on small compiles and much faster on recompiles after small changes. * kbuild 2.5 is slower on large compiles. * The speed problem is fixable, given time. Correctness came first. * I don't have time to keep tracking multiple kernels and architectures _and_ rewrite the core code. * Once kbuild 2.5 is in the kernel I can spend far less time on tracking changes and can redesign the core programs for speed. * It will get faster! Why do you expect a change in a development kernel to be perfect first time? Look at all the bio changes, I just did a full 2.5.1 build and had to disable 87 config options before the kernel would build, and that is ignoring all the warning messages which point to out of date function definitions. Is anybody complaining that bio should have worked first time? Unlike bio, kbuild 2.5 works, it just needs to be a bit faster. Put kbuild 2.5 in the kernel and I will have a faster version within 2 weeks. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 21:54:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 21:54:33 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:36368 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 21:54:20 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Larry McVoy Cc: Kai Germaschewski , "Eric S. Raymond" , Dave Jones , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 14:51:13 -0800." <20011228145113.I3727@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Dec 2001 13:54:04 +1100 Message-ID: <8541.1009594444@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001 14:51:13 -0800, Larry McVoy wrote: >On Fri, Dec 28, 2001 at 09:56:53PM +0100, Kai Germaschewski wrote: >> A couple of months ago, I came up with an alternative to kbuild 2.5. It >> doesn't try to have all the features kbuild 2.5 has, but solves the major >> problems with kbuild 2.4. > >So has anyone looked at this? Is this a viable choice? I've heard nothing >since Kai posted this. Keith? I looked back through the kbuild mail for Kai's suggestions, I may not have them all. RFD: Tracking indirect dependencies [long] We knocked this back and forth for a while. We both agree that extracting dependencies after compile is correct, where we differed was the mechanism. In fact I have currently implemented Kai's approach (lots of little files) as a stepping stone to storing the data in a database. It turns out that one of the reasons that kbuild 2.5 is slow is handling all the little files containing dependency data. [PATCH] removal of list-multi I agree with the patch but that was December 2000, in code freeze, and again in April 2001, AFAICR Linus had said "2.5 soon". This patch is worth resurrecting for 2.4. Auto detection of changed commands/flags That was a decent fix for part of the problem, but it did not address tracking user commands nor host compiles. It did not allow for separate source and object trees, for read only source trees, nor did it handle the more esoteric cases like modules being built from multiple directories. I am not interested in partial fixes, I want the whole kbuild problem list to be cleared. Fixes that only solve part of the problem tend to be filed and ignored. Kai, did I miss any of your patches? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 22:21:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 22:21:45 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:60176 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 22:21:31 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Linus Torvalds Cc: "Eric S. Raymond" , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 14:27:37 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Dec 2001 14:21:13 +1100 Message-ID: <8822.1009596073@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001 14:27:37 -0800 (PST), Linus Torvalds wrote: >Note that I do _not_ want to mess up source files with magic comments. I >absolutely detest those. They only detract from the real job of coding, >and do not make anybody happier. > >We have a hierarchical filesystem. Most drivers already have > > driver.c > driver.h > >(in fact _very_ few drivers are single-file) and some have a subdirectory >of their own. So why not just have > > driver.conf > >and be done with it. No point in messing up the C file with stuff that >doesn't add any information to either the programmer _or_ the compiler. I would love to do that, with each driver/filesystem/... having an associated control file that defined its config options, its help and who to make it. That is, an "Insert New Facility" file, we could call them driver.inf (ducks and runs ;). There is one big problem in the way, makefile order controls link order which controls init order. I have no problem with the link order controlling init order, that is far better than the old Space.c code. I intensely dislike makefile order controlling link order, it results in loss of information, we have makefiles in a specific order with no idea about whether that order is required or is just accidental. IMHO the link order should be divorced from makefile order and made explicit. Then you could have makefile fragments associated with each driver. But the last time I tried to break the dependency between make and link order, Linus shot me down in flames[1], so I have no intention of going there again. As long as you have monolithic makefiles, drivers.conf is going to be problematic. [1] http://marc.theaimsgroup.com/?l=linux-kernel&m=97301359812683&w=2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 22:58:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 22:58:18 -0500 Received: from panic.ohr.gatech.edu ([130.207.47.194]:17343 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 22:58:07 -0500 Date: Fri, 28 Dec 2001 22:58:03 -0500 From: Legacy Fishtank To: Keith Owens Cc: linux-kernel@vger.kernel.org, Larry McVoy , "Eric S. Raymond" , Dave Jones , Linus Torvalds , Marcelo Tosatti , kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228225803.A7801@havoc.gtf.org> In-Reply-To: <20011228161603.B5397@havoc.gtf.org> <7850.1009589209@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7850.1009589209@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Sat, Dec 29, 2001 at 12:26:49PM +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 29, 2001 at 12:26:49PM +1100, Keith Owens wrote: > On Fri, 28 Dec 2001 16:16:03 -0500, > Legacy Fishtank wrote: > >I think one thing to note is that dependencies is that if you are smart > >about it, dependencies -really- do not even change when your .config > >changes. > > > >What about a system where Linus runs "make deps" -once- before he > >releases a tarball. This in turn generates dependency information > >(perhaps not in purely make format) which includes 'ifdef CONFIG_xxx' > >information embedded within. We know that make can support ifeq > >CONFIG_xxx for example... > > Then people apply patches and break. s/break/update dependencies/ I assumed this was blindingly obvious, but I guess not. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 23:06:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 23:06:40 -0500 Received: from panic.ohr.gatech.edu ([130.207.47.194]:25791 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 23:06:28 -0500 Date: Fri, 28 Dec 2001 23:06:27 -0500 From: Legacy Fishtank To: Keith Owens Cc: Linus Torvalds , linux-kernel@vger.kernel.org, Larry McVoy , "Eric S. Raymond" , Dave Jones , Marcelo Tosatti , kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011228230627.B7801@havoc.gtf.org> In-Reply-To: <7861.1009589244@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7861.1009589244@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Sat, Dec 29, 2001 at 12:27:24PM +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 29, 2001 at 12:27:24PM +1100, Keith Owens wrote: > Dependencies _do_ change when your .config changes, the list of files > that are included varies. 1) "#ifdef CONFIG_FOO #include ..." is usually wrong and a bug. But that is a tangent and I digress. 2) Such changes can be expressed without regenerating all dependencies. > Linus, you have a choice between a known broken build system and a > clean and reliable system, which is slightly slower in mark 1. Please > add kbuild 2.5 to the kernel, Your system is known broken because it is 100% slower. My kernel builds work just fine now, your changes gain me nothing, while COSTING me productivity. I see no gains, only costs, with your kbuild-2.5 system as it exists. Keith the target audience is Linus and Alan and ME etc. We are the kernel hackers that perform kernel -development-. Making end-user builds easier is NOT a primary nor secondary nor tertiary goal here. Make my life easier first. Fuck Aunt Tillie. Aunt Tillie can get her kernels from a vendor. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 23:09:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 23:09:38 -0500 Received: from panic.ohr.gatech.edu ([130.207.47.194]:28863 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 23:09:25 -0500 Date: Fri, 28 Dec 2001 23:09:24 -0500 From: Legacy Fishtank To: Keith Owens Cc: Alan Cox , Christer Weinigel , linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system Message-ID: <20011228230924.C7801@havoc.gtf.org> In-Reply-To: <7974.1009590240@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7974.1009590240@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Sat, Dec 29, 2001 at 12:44:00PM +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 29, 2001 at 12:44:00PM +1100, Keith Owens wrote: > For people who know what they are doing, not for the larger population > that are struggling with the kernel build process. kbuild 2.5 is > designed to work accurately and automatically for everyone, from the > high druids of the kernel down to the lowliest newbie. Kernel building is not for newbies. I'm all for lowering the barrier of entry until it affects the productivity of people actually hacking on the code. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 23:22:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 23:22:30 -0500 Received: from marine.sonic.net ([208.201.224.37]:13170 "HELO marine.sonic.net") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 23:22:18 -0500 X-envelope-info: Date: Fri, 28 Dec 2001 20:21:39 -0800 From: Mike Castle To: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system Message-ID: <20011229042139.GC14067@thune.mrc-home.com> Reply-To: Mike Castle Mail-Followup-To: Mike Castle , linux-kernel@vger.kernel.org In-Reply-To: <20011228161603.B5397@havoc.gtf.org> <7850.1009589209@ocs3.intra.ocs.com.au> <20011228225803.A7801@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011228225803.A7801@havoc.gtf.org> User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 10:58:03PM -0500, Legacy Fishtank wrote: > s/break/update dependencies/ > > I assumed this was blindingly obvious, but I guess not. To YOU and other kernel hackers, yes. But not to everyone. Plus, as I understand it, it will be faster to: apply a patch and rebuild with kbuild 2.5 than to: apply a patch, make dep && make bzImage. Correct? mrc -- Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 23:44:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 23:44:41 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:38161 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 23:44:23 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Mike Castle Cc: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 20:21:39 -0800." <20011229042139.GC14067@thune.mrc-home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Dec 2001 15:44:10 +1100 Message-ID: <9467.1009601050@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001 20:21:39 -0800, Mike Castle wrote: >On Fri, Dec 28, 2001 at 10:58:03PM -0500, Legacy Fishtank wrote: >> s/break/update dependencies/ >> >> I assumed this was blindingly obvious, but I guess not. > >To YOU and other kernel hackers, yes. > >But not to everyone. > >Plus, as I understand it, it will be faster to: > >apply a patch and rebuild with kbuild 2.5 > >than to: > >apply a patch, make dep && make bzImage. > >Correct? As long as the patch does not change an include file that is used a lot, yes, a patch and make will be significantly faster using kbuild 2.5. What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more flexible and accurate than 2.4, including features that lots of people want, like separate source and object trees. Now that the overall kbuild design is correct, the core code can be rewritten for speed. And that will be done a couple of weeks after kbuild 2.5 goes into the kernel, then I expect kbuild 2.5 to be faster than kbuild 2.4 even on full builds. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Dec 2001 23:52:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Dec 2001 23:52:12 -0500 Received: from garrincha.netbank.com.br ([200.203.199.88]:49417 "HELO netbank.com.br") by vger.kernel.org with SMTP id ; Fri, 28 Dec 2001 23:51:57 -0500 Date: Sat, 29 Dec 2001 02:52:29 -0200 From: Arnaldo Carvalho de Melo To: Keith Owens Cc: Mike Castle , linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system Message-ID: <20011229025229.A2103@conectiva.com.br> Mail-Followup-To: Arnaldo Carvalho de Melo , Keith Owens , Mike Castle , linux-kernel@vger.kernel.org In-Reply-To: <20011229042139.GC14067@thune.mrc-home.com> <9467.1009601050@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9467.1009601050@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.23i X-Url: http://advogato.org/person/acme Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Em Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens escreveu: > On Fri, 28 Dec 2001 20:21:39 -0800, > Mike Castle wrote: > >On Fri, Dec 28, 2001 at 10:58:03PM -0500, Legacy Fishtank wrote: > >> s/break/update dependencies/ > >> > >> I assumed this was blindingly obvious, but I guess not. > > > >To YOU and other kernel hackers, yes. > > > >But not to everyone. > > > >Plus, as I understand it, it will be faster to: > > > >apply a patch and rebuild with kbuild 2.5 > > > >than to: > > > >apply a patch, make dep && make bzImage. > > > >Correct? > > As long as the patch does not change an include file that is used a > lot, yes, a patch and make will be significantly faster using kbuild And thats something I encourage people to work on: to reduce the includes dependencies hell, I hope to have the cleanup I did to include/net/sock.h removing the protocol specific headers from there and the cleanup that Daniel Phillips is doing in include/net/fs.h in the tree soon, of course if there's not issues, that we're very interesting to know. - Arnaldo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 01:59:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 01:59:21 -0500 Received: from white.pocketinet.com ([12.17.167.5]:59018 "EHLO white.pocketinet.com") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 01:59:07 -0500 Content-Type: text/plain; charset=US-ASCII From: Nicholas Knight Reply-To: nknight@pocketinet.com To: Keith Owens , Mike Castle Subject: Re: State of the new config & build system Date: Fri, 28 Dec 2001 22:59:15 -0800 X-Mailer: KMail [version 1.3.1] Cc: linux-kernel@vger.kernel.org In-Reply-To: <9467.1009601050@ocs3.intra.ocs.com.au> In-Reply-To: <9467.1009601050@ocs3.intra.ocs.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-ID: X-OriginalArrivalTime: 29 Dec 2001 06:57:31.0300 (UTC) FILETIME=[15E44640:01C19036] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Friday 28 December 2001 08:44 pm, Keith Owens wrote: > On Fri, 28 Dec 2001 20:21:39 -0800, > > Mike Castle wrote: > >On Fri, Dec 28, 2001 at 10:58:03PM -0500, Legacy Fishtank wrote: > >> s/break/update dependencies/ > >> > >> I assumed this was blindingly obvious, but I guess not. > > > >To YOU and other kernel hackers, yes. > > > >But not to everyone. > > > >Plus, as I understand it, it will be faster to: > > > >apply a patch and rebuild with kbuild 2.5 > > > >than to: > > > >apply a patch, make dep && make bzImage. > > > >Correct? > > As long as the patch does not change an include file that is used a > lot, yes, a patch and make will be significantly faster using kbuild > 2.5. > > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more > flexible and accurate than 2.4, including features that lots of > people want, like separate source and object trees. Now that the > overall kbuild design is correct, the core code can be rewritten for > speed. And that will be done a couple of weeks after kbuild 2.5 goes > into the kernel, then I expect kbuild 2.5 to be faster than kbuild > 2.4 even on full builds. > What, exactly, is the point of merging something that nobody is going to use unless they want to test it, in which case they can grab a patch from somewhere? It's half the speed of the current system. The current system works, no matter how horrible its internals can be. That makes the NEW system BROKEN. If it's KNOWN to be BROKEN prior to merge then it shouldn't even be in a 2.5.*-pre#. kbuild 2.4 works, but it's ugly! Let's create a new system! You mean the new system is half the speed but it's more attractive? Well I guess we'll go with the new system anyway! (sound familier?: Oh look at this new processor with all this fancy shit from ! It even scales to absurdly high Mhz numbers! Let's all spend a ton of money to get it! Oh wait, you mean this old processor that costs nothing compared to the new one outperforms this new one? Oh well, let's get the new one anway!) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 02:41:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 02:41:22 -0500 Received: from front1.mail.megapathdsl.net ([66.80.60.31]:37894 "EHLO front1.mail.megapathdsl.net") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 02:41:05 -0500 Subject: Re: State of the new config & build system From: Miles Lane To: nknight@pocketinet.com Cc: Keith Owens , Mike Castle , LKML In-Reply-To: In-Reply-To: <9467.1009601050@ocs3.intra.ocs.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99+cvs.2001.12.21.18.01 (Preview Release) Date: 28 Dec 2001 23:42:17 -0800 Message-Id: <1009611737.1434.14.camel@stomata.megapathdsl.net> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2001-12-28 at 22:59, Nicholas Knight wrote: > > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more > > flexible and accurate than 2.4, including features that lots of > > people want, like separate source and object trees. Now that the > > overall kbuild design is correct, the core code can be rewritten for > > speed. And that will be done a couple of weeks after kbuild 2.5 goes > > into the kernel, then I expect kbuild 2.5 to be faster than kbuild > > 2.4 even on full builds. > > > > What, exactly, is the point of merging something that nobody is going > to use unless they want to test it, in which case they can grab a patch > from somewhere? You don't seem to be reading Keith's message. The point of merging is that Keith needs time to fix the performance problem. Plus, additional testing would probably be helpful. > It's half the speed of the current system. The current system works, no > matter how horrible its internals can be. That makes the NEW system > BROKEN. No, it's known to be slow in some circumstances. > If it's KNOWN to be BROKEN prior to merge then it shouldn't > even be in a 2.5.*-pre#. Uh, many drivers cannot be built in the current 2.5 tree. Temporary brokenness is acceptable in the development tree. It is meant to be _unstable_. I recall periods when the 2.3 kernel was corrupting data for many users. This period lasted about a week, IIRC. The kbuild 2.5 system will slow people down, but not hose their development system installations. I personally think two weeks of working at a slower pace is an acceptable trade-off for the longterm benefits that Keith has mentioned. It seems odd that several people in this discussion seem to have ignored the repeated statements that Keith will have little time for dealing with the performance rewrite until the multiple kernel tree synchronization time sink goes away. Telling Keith that he needs to go on spinning his wheels while he cannot find time to deal with the problem you are asking him to fix seems sort of unhelpful. Perhaps you'd be willing to assist him in the rewrite? Miles From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 02:42:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 02:41:52 -0500 Received: from panic.ohr.gatech.edu ([130.207.47.194]:53186 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Sat, 29 Dec 2001 02:41:44 -0500 Date: Sat, 29 Dec 2001 02:41:43 -0500 From: Legacy Fishtank To: Keith Owens Cc: Mike Castle , linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system Message-ID: <20011229024143.A11696@havoc.gtf.org> In-Reply-To: <20011229042139.GC14067@thune.mrc-home.com> <9467.1009601050@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9467.1009601050@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Sat, Dec 29, 2001 at 03:44:10PM +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens wrote: > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more > flexible and accurate than 2.4, including features that lots of people > want, like separate source and object trees. I don't see the masses, or, well, anybody on lkml, clamoring for this. IIRC from the kernel summit SGI was the only entity clamoring for this. > Now that the overall > kbuild design is correct, the core code can be rewritten for speed. > And that will be done a couple of weeks after kbuild 2.5 goes into the > kernel, then I expect kbuild 2.5 to be faster than kbuild 2.4 even on > full builds. Ok... you want kbuild into 2.5 ASAP, only to submit a rewrite two weeks later? If so it makes even less sense to get kbuild into 2.5.x now. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 03:02:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 03:02:20 -0500 Received: from white.pocketinet.com ([12.17.167.5]:63118 "EHLO white.pocketinet.com") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 03:01:59 -0500 Content-Type: text/plain; charset=US-ASCII From: Nicholas Knight Reply-To: nknight@pocketinet.com To: Miles Lane Subject: Re: State of the new config & build system Date: Sat, 29 Dec 2001 00:02:07 -0800 X-Mailer: KMail [version 1.3.1] Cc: Keith Owens , Mike Castle , LKML In-Reply-To: <9467.1009601050@ocs3.intra.ocs.com.au> <1009611737.1434.14.camel@stomata.megapathdsl.net> In-Reply-To: <1009611737.1434.14.camel@stomata.megapathdsl.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-ID: X-OriginalArrivalTime: 29 Dec 2001 08:00:22.0653 (UTC) FILETIME=[DDCB12D0:01C1903E] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Friday 28 December 2001 11:42 pm, Miles Lane wrote: > On Fri, 2001-12-28 at 22:59, Nicholas Knight wrote: > > > > > > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far > > > more flexible and accurate than 2.4, including features that lots > > > of people want, like separate source and object trees. Now that > > > the overall kbuild design is correct, the core code can be > > > rewritten for speed. And that will be done a couple of weeks > > > after kbuild 2.5 goes into the kernel, then I expect kbuild 2.5 > > > to be faster than kbuild 2.4 even on full builds. > > > > What, exactly, is the point of merging something that nobody is > > going to use unless they want to test it, in which case they can > > grab a patch from somewhere? > > You don't seem to be reading Keith's message. > > The point of merging is that Keith needs time to fix the > performance problem. Plus, additional testing would probably > be helpful. The performance problem is fixed by a rewrite, which will be done shortly after its merge, thus, what is the point of merging now? You don't seem to be reading either my message nor Keith's. > > > It's half the speed of the current system. The current system > > works, no matter how horrible its internals can be. That makes the > > NEW system BROKEN. > > No, it's known to be slow in some circumstances. > > > If it's KNOWN to be BROKEN prior to merge then it shouldn't > > even be in a 2.5.*-pre#. > > Uh, many drivers cannot be built in the current 2.5 tree. > Temporary brokenness is acceptable in the development tree. Oh? Those drivers that cannot be built are a consequence of early work to get something ELSE working. Merging kbuild 2.5 is not *neccisary* to get anything else working in 2.5, thus so long as it's broken, it should not be merged. What is so hard to understand about this? > It is meant to be _unstable_. I recall periods when the > 2.3 kernel was corrupting data for many users. This period > lasted about a week, IIRC. The kbuild 2.5 system will slow I don't recall there being any intention to cause corruption. There is clearly intent here to merge something that shouldn't be. > people down, but not hose their development system installations. > I personally think two weeks of working at a slower pace is > an acceptable trade-off for the longterm benefits that Keith > has mentioned. So, it's acceptable to annoy developers and 2.5 testers for two weeks because a bad decision was made with full knowledge of the consequences? > It seems odd that several people in this > discussion seem to have ignored the repeated statements that > Keith will have little time for dealing with the performance > rewrite until the multiple kernel tree synchronization > time sink goes away. Make it go away. This is intended to first be used in 2.5, right? So concentraite on getting it WORKING in 2.5, THEN worry about backporting. kbuild 2.4 works for 2.4, kbuild 2.5 does not need to be maintained for 2.4 now that 2.5 is up. Make it work in 2.5, then worry about backporting it. (is there an echo in here?) > Telling Keith that he needs to go on > spinning his wheels while he cannot find time to deal with > the problem you are asking him to fix seems sort of unhelpful. If he can't find time to fix his own project, it's not my fault, nor is it the fault of any kernel developer that he will be irritating the shit out of with both the merging and the subsequent problems. > Perhaps you'd be willing to assist him in the rewrite? Sure, first you'll need to make me a pro at the language(s) in use. I've stated repeatedly that I am not a developer for the Linux kernel. I'm an annoying guy that tries to give the developers an occasional reality check, which usualy fails. BTW, Jeff Garzik (Legacy Fishtank) just said practicaly the same thing I'm saying, why don't you go flame him now? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 03:12:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 03:12:12 -0500 Received: from marine.sonic.net ([208.201.224.37]:48936 "HELO marine.sonic.net") by vger.kernel.org with SMTP id ; Sat, 29 Dec 2001 03:11:59 -0500 X-envelope-info: Date: Sat, 29 Dec 2001 00:11:24 -0800 From: Mike Castle To: LKML Subject: Re: State of the new config & build system Message-ID: <20011229081124.GD14067@thune.mrc-home.com> Reply-To: Mike Castle Mail-Followup-To: Mike Castle , LKML In-Reply-To: <9467.1009601050@ocs3.intra.ocs.com.au> <1009611737.1434.14.camel@stomata.megapathdsl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 29, 2001 at 12:02:07AM -0800, Nicholas Knight wrote: > The performance problem is fixed by a rewrite, which will be done > shortly after its merge, thus, what is the point of merging now? You > don't seem to be reading either my message nor Keith's. Did you catch the point, mentioned several times, that Keith needs to be relieved of the duty of constantly re-syncing the the patch so that he has time to do the rewrite. That is the point of merging now. Otherwise you'll never get the speed-up you're whining about. mrc -- Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 03:17:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 03:16:52 -0500 Received: from vasquez.zip.com.au ([203.12.97.41]:30987 "EHLO vasquez.zip.com.au") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 03:16:50 -0500 Message-ID: <3C2D7B2B.C1362850@zip.com.au> Date: Sat, 29 Dec 2001 00:13:31 -0800 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Legacy Fishtank CC: Keith Owens , Mike Castle , linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: <20011229042139.GC14067@thune.mrc-home.com> <9467.1009601050@ocs3.intra.ocs.com.au>, <9467.1009601050@ocs3.intra.ocs.com.au>; from kaos@ocs.com.au on Sat, Dec 29, 2001 at 03:44:10PM +1100 <20011229024143.A11696@havoc.gtf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Legacy Fishtank wrote: > > On Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens wrote: > > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more > > flexible and accurate than 2.4, including features that lots of people > > want, like separate source and object trees. > > I don't see the masses, or, well, anybody on lkml, clamoring for this. Clamour. The current system has some significant problems. Pet peeves: - Failure to rebuild the right things after you've applied a patch - Doesn't work when the same tree is accessed via different paths (make dep on local machine, build across nfs) - Mysterious recompilation of things which you've already compiled. > IIRC from the kernel summit SGI was the only entity clamoring for this. > > > Now that the overall > > kbuild design is correct, the core code can be rewritten for speed. > > And that will be done a couple of weeks after kbuild 2.5 goes into the > > kernel, then I expect kbuild 2.5 to be faster than kbuild 2.4 even on > > full builds. > > Ok... you want kbuild into 2.5 ASAP, only to submit a rewrite two weeks later? An optimisation of one bit, Keith says. I'd guess that his two-week estimate is optimistic because he'll have a busy two weeks supporting the patch once it goes in, but whatever. > If so it makes even less sense to get kbuild into 2.5.x now. Keith says it speeds up builds where only a small number of files have changed. For me, that's the common case. I'd like to hear more from Keith on where this 100% actually occurs, but if he says it's fixable in a (give him four) week timeframe, I believe him. As you know, I'd be more concerned about moves to drop support for the older and much faster gcc versions. If you're not using egcs-1.1.2, you're already a very patient person. > Jeff Fish. - From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 04:17:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 04:17:16 -0500 Received: from dubb05h09-0.dplanet.ch ([212.35.36.9]:49158 "EHLO dubb05h09-0.dplanet.ch") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 04:17:07 -0500 Message-ID: <3C2D8A4C.5FFA95C0@dplanet.ch> Date: Sat, 29 Dec 2001 10:18:04 +0100 From: "Giacomo A. Catenazzi" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i586) X-Accept-Language: en MIME-Version: 1.0 To: esr@thyrsus.com CC: Linus Torvalds , Keith Owens , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system In-Reply-To: <20011228170840.A20254@thyrsus.com> <20011228175832.C20254@thyrsus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Eric S. Raymond" wrote: > > Linus Torvalds : > > Eric, this is the _wrong_approach_. I want /local/ files, not global ones. > > First: where should the prompt-string definitions for capability > symbols that occur in multiple port trees live? Proposal: the main cml script in linux root dir should be as little as possible. it will include all the arch/*/ cml files (for really specifific options) and you move other item into the subdir drivers/ (the natural place, all file who should not be in driver/ are by definition arch specific). > > Second: Forward references, and references across the tree, mean that > there is a class of symbols that have theoretically natural home directories > but which would have to be declared elsewhere in order to be defined at > the point of first reference. > > (A potential solution to this would be to improve the CML2 compiler's > handling of forward references.) No. CML2 could be improved to handle che forward references, but not user that will use line config. > Third: I could hack my installer to break Configure.help up into > a bunch of little component CML files distributed through the tree... > but Configure.help doesn't currently contain any markup that says > where to direct each entry to. The Makefile should help you. > Fourth: There's still the localization issue. If it's your ukase > that this is not an important problem, then I'll accept that -- but > I haven't heard you say that yet, so I'm not sure you've considered > it enough. PROPOSAL: You add a tool to build a big file from the sparse symbols.cml. Translator will use this file as references, adn your CML2 will use translated big files or the default sparse little files. This should not be a problem, because a translator will read documentation (unlike the most user), so you can explain how to do this work. (And the 'diff' could be a friend to the translators). kbuild-2.5 have already support for 'clean' driver (clean: driver that don't touch existing files). I like it. If CML2 could handle natively also these change it would great. The problem is the use of multiple sources dir. I think you and Keith should coordinate this work. And I find clean if also configuration files go into makefiles. giacomo PS: Keith: How you handle the obsolete files? (foo.c in the main source. the patch in source src1 will remove this file). Actually I have create a shell script kpatch: a new implementation of scripts/patch-kernel, that handles normal, testing and testing/incr patches, dont-use patches, multiple sources and new (and clean) destination dir). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 04:38:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 04:38:18 -0500 Received: from dsl-213-023-043-128.arcor-ip.net ([213.23.43.128]:29712 "EHLO starship.berlin") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 04:38:01 -0500 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Andrew Morton , Legacy Fishtank Subject: Re: State of the new config & build system Date: Sat, 29 Dec 2001 10:40:33 +0100 X-Mailer: KMail [version 1.3.2] Cc: Keith Owens , Mike Castle , linux-kernel@vger.kernel.org In-Reply-To: <20011229042139.GC14067@thune.mrc-home.com> <20011229024143.A11696@havoc.gtf.org> <3C2D7B2B.C1362850@zip.com.au> In-Reply-To: <3C2D7B2B.C1362850@zip.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On December 29, 2001 09:13 am, Andrew Morton wrote: > Legacy Fishtank wrote: > > > > On Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens wrote: > > > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more > > > flexible and accurate than 2.4, including features that lots of people > > > want, like separate source and object trees. > > > > I don't see the masses, or, well, anybody on lkml, clamoring for this. > > Clamour. Clamour. Broke my tree yesterday, rm -rf was the fastest/easiest way out. Immediately after make -j2 bzImage, make bzImage seems to rebuild about half the tree. Many incidents of time-wasting breakage over the last couple of years for me. > Keith says it speeds up builds where only a small number of files > have changed. For me, that's the common case. Ooh, yes! > I'd like to hear more from Keith on where this 100% actually occurs, > but if he says it's fixable in a (give him four) week timeframe, > I believe him. He said something about reloading dependencies on each compile. -- Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 04:30:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 04:30:06 -0500 Received: from samba.sourceforge.net ([198.186.203.85]:60429 "HELO lists.samba.org") by vger.kernel.org with SMTP id ; Sat, 29 Dec 2001 04:29:55 -0500 Date: Sat, 29 Dec 2001 20:24:37 +1100 From: Anton Blanchard To: Alan Cox , Larry McVoy , Keith Owens , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011229092437.GA1295@krispykreme> In-Reply-To: <20011227180148.A3727@work.bitmover.com> <20011228094318.B3727@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011228094318.B3727@work.bitmover.com> User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi, > Taking nothing away from Tridge, I like Tridge, I'd like to see numbers. > I'm sure that Tridge's stuff is great, but we were very motivated to > go well beyond the normal effort when we wrote this code. How large is your core db stuff? The thing I like about tdb is that it is very simple, only recently growing over 1024 lines. Anton From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 06:10:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 06:10:33 -0500 Received: from a212-113-174-249.netcabo.pt ([212.113.174.249]:9761 "EHLO smtp.netcabo.pt") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 06:10:21 -0500 Message-ID: <009801c19059$754aa5c0$d500a8c0@mshome.net> From: "Astinus" To: "Arnaldo Carvalho de Melo" Cc: In-Reply-To: <20011229042139.GC14067@thune.mrc-home.com> <9467.1009601050@ocs3.intra.ocs.com.au> <20011229025229.A2103@conectiva.com.br> Subject: =?iso-8859-1?Q?PORTUGU=EAs_EM=3F=3F?= Date: Sat, 29 Dec 2001 11:10:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 29 Dec 2001 11:08:40.0272 (UTC) FILETIME=[2BB2ED00:01C19059] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Ola, estava a descarregar os meus e-mails da Kernel mailing list e nao pude deixar de repara no teu nome Português !!!! E sempre bom saber que ha portugueses nestas andanças e dispostos a ajudar. Bem eu tenho dois problemas que quanto a mim serao bastante simples de tu os solucinares !!! o 1º e so seguinte: Eu tenho tido uns problemazitos com os meus controladores usb que jah resolvi, e portanto consegui recente-mente que o meu kernel detecta-se a minha unidade de gravação HP8200e. O aparelho aparece nos scsi devices como devia!! No entanto eu nao sei a que ficheiro do sistema é que ele está designado.... ( sda1 sda2....... ) ou outro qq. Gostava que medisses como e que isso se descorbre, uma vez que nap aparece nada do fstab jah que quando instalei o red hat 7.2 de opri9gem ele naop me r~econheceu as saidas usb, o que so aconteceu numa compilação posteriror do kernel. o 2º problema e o seguinte!!!!! Eu estou a pensar em comprar um computador novo. E o setup que tenho pensado é o seguinte: Mother Board D850GB AL 46800 Processador Intel P4 1,8 GHz 70800 Disco Rígido Seagate Cheeta 4Mb Cache 10.000 Rpm 32 Gigas 110400 (queria o de 73 gigas e 16 mb cache mas 300 contos nao dah para mim) Controlodor SCSI Adaptec SCSI Ultra 160 99000 Placa de Vídeo Matrox G450 22800 Memória Ram 1 GHz 119520 ( 2 rims de 512 isso explica o presso a gb so trabalha com rims) Drive de Diskettes Drive 3.5 3000 Cd-Rom 52x Creative 52x 8640 Caixa do PC P4 Tower + Cooling 44160 ( o cooling adicional sao duas ventoinhas de 11 cm de diametro ligadas directamente a 22~0volts) Total 525120 ( preços sem iva e em escudos ) E eu ecrevi um setup semelhante numa msg qu emandei a outros gajo e todo eles me disseram para investir em athlon que o que se poupa n ram e no processador e na ~board dah para investir em outras cenas!!!!!! A minha per gunta e a seguinte: Se eu investir em Athlon 1.8 GHz por exemplo, que board e que escolho??? Nao gosto das Asus tec ( ate podem ser boas mas nao gosto delas ). Para o pentium era simples INTEL e pronto mas e para AMD?? Qual e a boarde de QUALIDADE e que tenha uma assistencia convincente??? Jah agora mais uma coisa, nas diuversas respostas que me deram acerca deste tema disseram -me o seguinte: " Ram => 1000 mb ram 2x 512 rims That is an unfortunate amount of RAM. Rather than forcing everyone to run their OS the same way, Linux lets people with smaller amounts of memory avoid the overhead needed to handle large amounts of memory. There are 3 configs: 2 MB to 896 MB (fastest) up to 2 or 4 GB (upper limit depends on your motherboard) up to nearly 64 GB (slowest) As you can see, 1 GB is just barely into the second config. You might consider instead 512 MB, 768 MB, 1.5 GB, or 2 GB." E SOBRE O CHIPSET O SEGUINTE:"Don't get a VIA motherboard. Linux 2.4.17 has workarounds for the two most serious problems, but still... VIA tried very hard to hide the problems, even blaming Creative Labs for a while From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 07:29:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 07:29:45 -0500 Received: from smtpnotes.altec.com ([209.149.164.10]:63238 "HELO smtpnotes.altec.com") by vger.kernel.org with SMTP id ; Sat, 29 Dec 2001 07:29:40 -0500 X-Lotus-FromDomain: ALTEC From: Wayne.Brown@altec.com To: linux-kernel@vger.kernel.org Message-ID: <86256B31.00448FB2.00@smtpnotes.altec.com> Date: Sat, 29 Dec 2001 06:01:44 -0600 Subject: Re: State of the new config & build system Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Legacy Fishtank wrote: >I don't see the masses, or, well, anybody on lkml, clamoring for this. I'm one of the masses who are *not* clamoring for this. Neither kbuild 2.5 nor CML2 will provide any benefits for me; I'm going to be enduring them (because I have no choice), rather than welcoming them. Wayne From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 07:44:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 07:43:53 -0500 Received: from d-dialin-321.addcom.de ([62.96.160.81]:50414 "EHLO localhost.localdomain") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 07:43:38 -0500 Date: Sat, 29 Dec 2001 13:43:07 +0100 (CET) From: Kai Germaschewski X-X-Sender: To: Keith Owens cc: , Subject: Re: State of the new config & build system In-Reply-To: <8541.1009594444@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1168928013-1009629787=:2889" Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-1168928013-1009629787=:2889 Content-Type: TEXT/PLAIN; charset=US-ASCII [CC trimmed] On Sat, 29 Dec 2001, Keith Owens wrote: > [...] > Auto detection of changed commands/flags > > That was a decent fix for part of the problem, but it did not address > tracking user commands nor host compiles. It did not allow for > separate source and object trees, for read only source trees, nor did > it handle the more esoteric cases like modules being built from > multiple directories. Some people asked for what my patch looked like, so I resurrected it. I moved it to 2.5.2-pre3. As it caused lots of rejects (maintaining kbuild is a non-trivial task, isn't it, Keith?), I only fixed the problems for my .config. So the attached patch will break with most .configs. However, people who want to take a look can take my .config and play with that - it's strictly proof-of-concept only. (The breakage is easily fixable, it's just quite a bit of mostly trivial work). And yes, it doesn't fix the separate source / objects tree issue. But IMO that's not a problem that needs to be fixed, it's an additional feature which I didn't even try to attack (it may be possible to get there with VPATH, though). To try it, patch your kernel, mv ../config-2.5 .config make oldconfig make # builds bzImage and modules A subsequent make will only rebuild what's needed: [kai@vaio linux-2.5.2-pre3.kbuild]$ time make make -f Makefile.build boot make[1]: Entering directory `/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild' Generating include/linux/compile.h ... Preprocessing arch/i386/boot/bsetup.s ... Assembling (AS) arch/i386/boot/bsetup.o ... Linking arch/i386/boot/bsetup ... Compiling init/version.o ... Linking vmlinux ... Generating System.map ... Building arch/i386/boot/compressed/piggy.o Linking arch/i386/boot/compressed/bvmlinux Copying to arch/i386/boot/compressed/bvmlinux.out Building arch/i386/boot/bzImage Root device is (3, 2) Boot sector 512 bytes. Setup is 4764 bytes. System is 715 kB make[1]: Leaving directory `/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild' real 0m10.230s user 0m8.510s sys 0m1.050s For each make, compile.h is updated, thus causing init/version.o to be recompiled and vmlinux to be relinked. - I kept the behavior of the current kbuild. Not regenerating compile.h will give: [kai@vaio linux-2.5.2-pre3.kbuild]$ time make make -f Makefile.build boot make[1]: Entering directory `/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild' make[1]: Nothing to be done for `boot'. make[1]: Leaving directory `/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild' real 0m7.155s user 0m6.790s sys 0m0.290s As an example, change one file: [kai@vaio linux-2.5.2-pre3.kbuild]$ touch drivers/isdn/hisax/callc.c [kai@vaio linux-2.5.2-pre3.kbuild]$ time make make -f Makefile.build boot make[1]: Entering directory `/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild' Compiling drivers/isdn/hisax/callc.o ... Linking module drivers/isdn/hisax/hisax.o ... make[1]: Leaving directory `/home/kai/kernel/v2.5/linux-2.5.2-pre3.kbuild' real 0m9.433s user 0m8.780s sys 0m0.520s $ diffstat pp-kbuild-2.5.2-pre3 00_version | 5 Documentation/DocBook/Makefile | 3 Makefile | 507 +++---------------------- Makefile.build | 460 ++++++++++++++++++++++ Makefile.config | 32 + Makefile.end | 37 + Makefile.vars | 130 ++++++ Rules.make | 326 ---------------- arch/i386/Makefile | 70 --- [...] scripts/Makefile | 23 - scripts/fix_dep.c | 406 ++++++++++++++++++++ scripts/mkdep.c | 628 ------------------------------- 169 files changed, 1849 insertions(+), 3107 deletions(-) --8323328-1168928013-1009629787=:2889 Content-Type: APPLICATION/x-bzip2; name="pp-kbuild-2.5.2-pre3.bz2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="pp-kbuild-2.5.2-pre3.bz2" QlpoOTFBWSZTWQKhAD8BAnf/gH/8AhB///////////////9g5X719816APIC 5gEnfezr6z0Bvo6B0Pmx9DFEV5ULbXW6waqegHfbXw6z4VdWoaek0Wb2Xtp9 9j4Yb6qm31we0enL24QdI2PewaOnodmHoANt6envZqpXu47bvvcMAAt9ZR59 3CunvZ7YVlVC7PWhfOiW+sHUOig2y8G7316T433AeuSvI6NANvOSF99i63Ab h9mwC3j1Cx9091b302bZ6813j69fM3mdI2aUooBQqlSBVJ9qaAK9VL4DRfJT Xl3l93lyO03Y5c9XW7uvXq7XezI9nbddud7bnu7iQewc+AF53rHz75RCgFcq 519fbV19F7vU8uE9fPavIVj77u3vPOvTr2YVze73e69bu3XXfecS72U+93t6 T1ofLcZ9Dtr7vXvbdFtF6dcOL26re7tvdozfdzMefb66+vdb273g4dd57d2+ 7nGTLML7bbXPurqLrTNvA1d73vby+4x3sd9e73Y1W1Fqp2u7169bJ8Dx7j6Q ArEorH3vbvEfXo9m9GyrdndY9565rbPvtcYV7cL3uvr19Xs6Bzeu6vu+e997 09IXk1H1e7Te3vmenvN93cHsc7nEbp9eOt3e+9x8mHXPDxnae3C7Nmy9AV2t 230d7eF7wzXOrZ2We7e8OHdraNu3Omvow+3mLPVXd98Prvufe054aPvfT142 tgYbezXg0NbUmDXs7d9z3W+tS+2tKwAns7d1hqNhNn3uA9mpadz051kE86yr t3G3a3a4y997d7i33wlNIIABAJkAIAAmmmTQEwhMIwSeSZPUT1No1PUEpoEI IQAhMjQTaTFT2ikep6aekR6mmQaNPUA9QPUA00Ak0kSBAmQmEnoBAE000ynq aYRqe1T2gkaeo8k2o09R6jJoASeqUlGlGKemp6j1GRMaj0JtDQTAhkDACekN NMIxMJhDCJIiaBomCnpTxGQmRT9U/U9JT0w0TCZNMEwSYZGKbCm0jIESQmhA IAQFNkmmVP0U2NVPaGVGPUbVM1PUP1TCPUA0AAbnqeEZsX+ZcbsbMJEkUCSS QSMQ230Stby151tFZLFQbXPwl4AjAEhACQRgAPgf8h18f5Y3tCvfYwwf5X/8 s0cNa/+9ndR33cpA11qbjlCoRinBq0OZlG2KUSlQoRRJyLqa1Q/5f88mQ/qO nJWLzCs6jJKqEHP8sgbGHXd585JJIQzin8lNQn8lPy6qKJppfubdsvE2zKEx 06Zp0k926Ybabb+6yZ1snHHHmRFSAkMo/4Eyw+4tP1H+RMIXTN5mfItNaIDJ JGCMiYMuWYzSF0WopClpoQxUMYxMGqhg5hQuYZWojN4fzYUiIultWMIstqqh ulRtjSiEuF5IS5YaT4XlsDWKtJBSCn7yTH3x15+um1VRVelhTfsDMVYCCExs gqtZO/MHBdpAqEDohMYGKGiwK40VZEmWimJs0d+BxxAPj8eIZDh4500OMGCN j3SnVgeOFVAROEqKmvfYZCIrPBqxJ77QDLZI8UqMFlgE0aJd25QYpTSWJGbW LDO7p3XCuu7SYghRk5h8UuRzwO7y5r2t58hWsoFGQ+J3M64QvILIahd4f0Hd dif8U2/OJL5BU9hhmP3u51ngmYW2wVa1NU1kNNzueNF0iNtCqKoDu2Iza8Zr eytxuIpUFwFlq0LSy7zFKZmpqNxzMoXLTaQsWCyMEgIiynupA/qOehmNODJh 7IHqBZIwkFEBVUVd2sAAA7uADAL5+q30Xun7lUP3YAphjLgSwFJp/34WAF0R TpAQtADKI2thMbmMkUMu6hTadIazqUYDO9MLqDGI+BreUbSk0mhMXQlx0lEi VwKRBDLG42tmBUbGbSmhoxKMLNErlN5QWLpRZaTQyj7HjcmkihhWCUBsRgot GxtKo2jvFdZMTQCWaXWrhYaFBwQomCRERZg01EM0EzDTDLEagphSgJo0VHCy mJCiKKrloma3rJouzBuVUKtuh9+XTDecYGmygqyUkSljBf1obIh+KNa873ZL /9/36+OWKaJMNxb91/+rLUL/x4/zL6ceXU/5z/u/hguiPOUfxp0yIIoH+6yv PblTD25/Vr+/W5iF3h+pBZpKf9GmIR9V/5qr6kNMUN6pyb2ulVmqbWIPJ2ZI PHfPfHw1OxTIcdXf8OXSjC25OwRR37uX5yxhdz5+4d1Ol06ae7Pg97jjSlSZ 0S7pxx31HClnpfnd285zRG+CuRQJITE07ntcx13bLKCGzwO1aZp34QM1wXTE hXcaq4BgmNXVXRG7Dw+mU514164mCZmJqtDGUE4hGFGVbs5bq/jZYrP9tDqy dWQetm080RD3MAdkwwkwViU1POGqEdI+uulkkgSZaL6NXmv8kKPEcYYr7JjY N9/dZbRzAPWfzjeHui6QNkV0y55lEDqTMalomAikGri9kMobrHBWJjKDlUI6 TRRJfu4w02okQYigIwQUVJUKwsgrIFoH727P7w0Biff8Lua5N6LYZVSfZXb/ jTyuYKTEJ1/+CCPa33WXc/Ch2x7dLz3zXA+H6qfZxxDLxa57k+5hp9z5pWfk t9ycPP50DknXLiTE9wkrUm59DpOyuvPVuqVrF0nfcyfw+fGyctyhwlG1oUa0 ZbYMQrFolcZji2WClpVpmVxcsuJSNbdXByiwUqUS1va4ZS0W2ngyuIViqsvF xBuXBUaicONoZiGkxMR+bV0NFH5PbVOPxXzdfcldpq26ToatCYwhCHObEwwy QL4OA57HKAtkfou6vrZYXqqkytlCwv/Ywwkisl7lPUPiX3NGkYm98A7iZu9W o7VCmnUN0DYTZUSC6f/vs5982KGKzjX140njaJgjRlizVDP5Q/ePsUEkrnT0 I671rnsCNdEXnJtlzvXtoZt5km4a+EZDS55DoQm9JTr8ajWfLAZEzQmScRCG wJa+OMNRo9G7bEmgQOqKH75JVsjY5zqudvtfls8VElOZkLp5geDIF5UNPNm7 ZEUIQkyTIWs/r5PT4t+2xMhL5kWwdtTuKZA1Xyz9b05eyBj3vakWO7OjpFB5 PSGiE9/z3bIrpckcvF13LaX0eGlPshtH7Y36BYjejgiWWls1vz69lLRscvbX 6PDO++gXhhCWa2WRVf/yF8YqjOzxKju6roakSEhqr5QKgl8fvjRxnV/KNO2Q jyJnQhnSTOIQLtQ9jZiuZWZ+383EN8WZkD8Sf3k/OTMOZbdyXr+/E4FPoQ1a Zf3cdkIEhJkJtPcVdm6UJsxj6fNA1pBf0w8sfN5bvKMFkgYdGah77iFCftc9 sXi5akhVuONHxZeHVb0+iia9a++dvdd6qZ4Sn4CleNNtpsNS9jCTcxT5OL+j gnqcfqqOfl5/XzPRFtarjTKit617JDPQ51K8zfU/Y/1SljUSk/l7chk0xkAx gqjQCwyZTEFRgkWCjBUR172T+Fk9b/q91O5486fKL/cr+5/F0+iHu22wPPc8 cYqHFZ9vD/Oq6Hh5cxrhj8KPJT04L/nuJ1FNmWsqwjfhOGErOVOlBw0h4FWR ddrq6EHd0+zo8dZei2j0cOPCP87nbWqPjX0Td0XXSp/rj49VaY70FyYYzTeT yp+MTMXSVeUyKkhIFeVK2tPz9u7672Nvb+jq/Rx0u7qSrCa4Q/7oj/9c7l8k x1et2onzbOvsL6JLuUWk5Wj5sX+QfFHCZFm4pvbXSq3e5Sv54mrySZzZHPf3 QmyIHfzvssqnx8D1HYY5dSIqVjuyri5FRJs7JRggoR0c0OyMhMUuzt4Vff5Y NZ6+foIpo1cnIpoCEkiyGso+Tan6L6sO7M5mk4XSuZWY5mYFebmtEtSqY4/T lRTGpT8W7lfg7xPL2aXjRvH9eU93W+5ONnPnmd1xzGQqTalZVkMYxGPWhxlA Y+nVqKuOLtptysystRDDwxflJ0VvML0zReNJPD+RR8lRfeV1dasyqgz7tyfx GbMh8WZM45ag6moOpbDVlGhS0RtEUMwozRZ7vXo4SBoVOGG2EPf2+EPj8o/a 2/aEjCU4yLCEGB8kzaUu4IGGtentsq3CVBSPF3J9tVIqUcp18ojaTHw8BfUu nldJMUpkJZTuhAVw4vZ39SY2xp2TlzLdrqgQtt+dtYkJMgQ2shAoIMkWREHK HxO2tnPZ86CM8P6W8yYxz05TlIPVLDO2VdAafXAMUyEGCaVqhAL6XtRWBFTJ HbPT7abYFsnR2jyg0JJI85I3c2CKElw9OUe4s9qA716okuPhidGug+PRVuS6 4JnkjTJmSGTIo4ZU9wvAvJCqXZ9z8UGSJ1J4KDtRym1dHPQQyEzJJl7HOC9c SE4Gwg/gv50Y2/DMb0w1SnOucYpRfzO+x7semjsq41RXyT9et6356WCaFbHw UYqALho/RR7tXCC3ThO6GPkki701z7474UEFw5lqG4phJ1o7MOqK+h/jDu4W fXdfT9uL2efxW8RRdMSVqgoENpBfrv0L6FST8OqiAHX3UwW7fsg18lxp9nW9 nKizLQyGeWO9+Z7P0St16bx5J8CSPRfYg5moXCiEn8nIxFi9hmCfXoxyLIs3 b9l785M6s9n9N27EkzVIVjOOJKlNjCz0atkn4WVAiwRCD5UqUL8uCeUgTITC b7b1LnEdUT4z2ifmY/Xat+lRrP2e7NxyVcY83a5JK8Tsk74qBY99Py8zR2xC Qk8BomcsXC6yyWkdZZTj2f5S042H/NMfdfXbw/34vj5bfgxGsZNzJ0CSEu6i arq+avfVUBsQxRT0ciEQKdOUGy63WPcft/jcaxYBgdw96GjdY7fwiepx4W8x Nenu9x29vhe8F625bztUcpjgRMSEBqohwmfviqlDIgTJnRtj8X3/H2v5qs8P 39GGDtdkhmChtue3Ey9E4uj11OddfloiO9KboYSDmeXrdLxJuf0UzDpJM2dp q6FugADHWf+oUNYjv274MXnldhu1MwX240INkinBEIaofT8ColFZoy++Pnj0 9qYEgEmSYEKKHERhfCH2xJ6lla+6T3KtXR3qPWpB265wK34KmjBzQgGXgs+7 vona4DJCTMcyBnd2Ds9NWLARGIqkiqeu1YPs7/0/Nv6P5+7GprTnWo3Ocjkb rKShTEji7OIQCTISK/D3oyaSJ5pVWKryvv+GjD4/JMw5vbnTwT7Mc9kcGJJj m54W3Suo8FdBLyVY5RAsm7FV8CHRhzzK1fTTnhVOfLMEFFFQ7/OmVlIpO1uX u+WpofqfanHh/J7/LWxVfCyqz2cvI7tbcW3uwuQ0bY0oyxQSKosbQIwCWJWC +8M95bM6JWVNj+i4+CFZ6IVCK7J7fA9xnQThOQQvIRBZDGsg/z3DK7sJU3IN 1mIMxkVxypmRFgpmnMQYLJoIaD3bNorNtRBIsA1lz9lDMsgs6bArl0yFUnhP BhmI+NsrLMNYaz+NzTy44cP02r9PptmIP4/Z92ZmeHr3Dod5CkqqndCd/68p VVfmp9JAn+xFDk6YejBblMX3/quaH72UxIHhy1p9XcMO9nze4mCBPC++ZOqo BAgF9duLbj679EXTo0P4tWCFr0qSBYyuFhOmrh7d2PL7vT7lduMn5/D2ahfK 3rZ7MPDt+/s5G9FpiZFrYsHFwj9nky9QOUQlEGZ//YpdHftWFne4F4Jqw4CH SWiJTH1ofk2Hc4w4rxTpo1mOemSSAO590J/gJmwU2iMlgvCkr7cfWu8uGEGE yQSif2Zq96/PiqgbdqRLREcQRecVecJEH52xYTadu8tLLmBxJ/XBHWJoRBHM ECogLpAZEFO6CHCJFBB/vIGZEBB9v5Cgdl/rejbRCm2jNLD44HkjhTziV8iv 57rqhGEkkhEDIykkOxKhSgVYZBLJwdbMaB57JqGhOHgus0xQVIWlCVofgEKE 7zvPA+MFfF8B9VsHe1tSVlwh77pR7LntXrN5M9LvEKWd2awIEIFaCGWWI+lE yH+qvmZyqnslEehtXnlESFhhNVCBOhzDUSiVrCs+AGqwwlRcUEh2AQZpgdDf t9uzq7vzx8CtuToNNbxUUwb3doIATu2sh+EJSeKFZS26s9/T6f9H4DciYfMg Zy7pgmYiuchQW0Y9/X6iPZ+SUCcDcTajz0BzTjFm6udHOrQHTMsFU8rzMDwY LKjxZPoN078R+WHZ/F+W+iz+3usu69DIp56E3fepqqKHoUBSYjTUBH7h+hhh olwQ9aHRDUFi8Lejnyp1QhejJsaYvhE1RxlXP+nfLesYnr7thkbN5PIC058A mmb5xNQbS0IJv8QLbP/Am7a9UKUd0kFXLBDLdiaGEO2d+nHHdMMplh7EFT3k EVkEGSGZsKgKiHEs1EcAoBGgXB0BY3zdofh7vOO8atGoGOXtK8JtUXrxUxMo 8hDboDm6XBA2rmRQPBrHJh4h4RJDTcBI+w9jswXMTGegr6nDVPzeXmutKwdk IYP8ufnLNYmWt2SbFNB3oxMyuEYrge8s0ngzgebNclW/YIY9rOAVSRVnzURo nT+bU0phMAjMq/SYEsfSZFIuO1+MIdNtUIYmESoNXXBg+oRFHQmqgPT01ZE5 JYOknFsT0xYdxWeZgkZhn2fGP1OhopAeobh8gLKG+PyQgoKqjvsI1+pbNVnG KAZgnQo9/2jkNPt3EapShebjccTMKi466z9BY9jlZ8m4SYJPnAhB5Rd1GLju 8KIsiIcj6JPMqfvb4Rk9XO5AXoVJnWk+gd0krNN4N8W7C8A+2/F71pJLnRuS SkKYZBCvcT9xKZDU6cXJ3755WBSc5xwurbvMVe1dKqdjtF1NhMQkleXhQ7u7 vSIiu5sVlXerDszJmORVSTuPr3rQs7TL/Y9Fbm7ImUyQOZ0PMsWhzLbXjDum Plj+UJZMn9bNGEuq7bEZpR9lqqumjYF8unTyp48QnHJbA8yJudDtB7xsdTVh 5J2WPfCCUHdJ64EIjvaGFnzb6qmRTSr62bmj51QmYUXEJlzwaGqZA0R3roRw XC2A+n8hvq+O/1a2io69sHh6M5KEtGNSGI2xMN7jwniQwIXgDICkgbntzlPO Dth8gz6BcDv8eR4bnWqeInKcPr3up2SBMwQBJmd3bVDjx2/Tr/v+/9O/+Pj+ wPNLP2YMHHk0RBccSEWTMGiHMWQRyHCKfqhQlttLbDIET4EVLGpVw7ef3Yg4 wG+whgiFHj9bHBx8QPQegCvXB74XhI+iVBOv0AMG0PURzQwW7FMKbJ9p9lZZ GmuZS9hrygxstoNDdB8Ny6fvgUTWGFYLYeFB++J8dfhpfEo/T+Ysnb6pN96r l8zupy7dVp2K53Tv0w8VLc9ySYS7KbqpYW2/rlDVTBIuucKLv5V+idKojm+v AY9oCYTAlb6zfJK8ZikYhJEkmEBPnCoKsC0RaSV+gQriUvzcfe3WiFJwG7gL FaB0eMCeu73fs0/GLM9mYcUQR1Vv9cI+39P0nXnSMcjcXbu8ZMkvJyaHR2ho G71r4WbIO1qarzzvxOvC7+HkfwO68LumXuSkh//M3k54kIon8/+Mp0wgxSsa i6cxkKjCIeozqVU51EzlEXEIl5MRGc1aqs1eLZsuLUzVal8EGXE027qStRhY cxAniFeLmtZxjL3FPDzmh4y9YmCNZuVprg1miby76MM2sCvBLp1iHmqw8azS jJj+bfxX9AHkLP6wyB6e3Xr+BNqqfwHMs3bWSsrUUclCsYigEFMtwQ6YttuJ CsUWW1HXKzENT8dDEBYLAwTk4zDfTNCiSCrFDnaIgVNp+fr9E7fgnw8PlP5v CvVz1Ntu+iuThah02CBJgbn+P3zGPiBVo7DDH6fgUAIbtlKfQ0CSCf2GW2P5 ZfdC/9pddxAIu9HvJuxVeoOI/Pg0pr+Q0mNhq+uR02fhviEERelvEsXq2SWN GkxO8x+UxaSEMP8zLsDuQRK/iQU2oOo46dB/KdaS60B7ox7yPrxP3Hbc2owN Z7yIgscZhrH2QYe6k/ARZDVptgQL67ZjZXzkCV6RxNfW3euJ4J9GmWzQqm0R ubUTLTMQe8TbDykCBARUcYkGYIfycN0besyDk4zmwACq+A/JXJMMVU3w8d8R BQ8p/P/BL+Y1OfRn9bL0pj4Yngfb31aewdJop8Z3WMIdvSNKAQ1eS7PsEeCS kPR9TfQgffvCmg8z1o7H6ig8EES/EsQxo3HGLOqHXQNdZ+P0Caomr3du+2Nu NbP0XbfTrQ3j4ftKhvwAY/mQZqURMGOf+UIiEmifP44RVBrKiECKTMJpUIeB 0J0UN4v3X9lZRoTQaxByKx/aUbAhdR+iuLMSDx1O1VTE5RGkk7wkd0PgzfWe EX3LjZIY+v7F9rCBUUnu9ykTaI6eFjGpAIR6eYDD8V7hjdDh3/NzNGik8etz 3trGGAuwnE6SMmYaMv3/XHOU2Qvifu9M8e81nOI9vUutDH7an5V1fsV77bTb +XcaHcPKd4bOio7S5oO71TuNHwQ47h3bwJUXxAbIeXh4RY9vh5Pmj7IpVH++ 86HjGz3hyVmMXrF4kWtPl85yqhnV3aStXp8j6pPNPMmqHWECfKe3y5pPBCyk 6qHNLGXLTVUQhTKcISSPTUN9CzTwnLnvN1qnNhUy3GGPCVJuIbEu6GhM6CGv UOoWrzMtFPaxl8JrQ3495OsWfLzyXtXjMCnl2FSGBoFHLh0YHqAMGNWo3aoI NQkwAzbdMjI276ea1momxttg0AkPcKDFR4iF6Og4uTGazlkyyEx5vdj0L9Sd HZWc/vonEH6IT4iauYiIWFE3MjTVX+Y7Qv1n+3/TvB0Y81RN+EYsJISEiyT+ H6sLz/pHnr30ZJCO12+3MX8S6aWVxVkKiGCZCBJvKIfQdpBLKHhhgt9R7fu1 /Do3l596XA5Fta7pmZ/hmGaswLQT89uWFF5tUUXGNr0ypwJdG2iO6XEom6dU 8tay2wvLDKmJES8WUYZaVim2ojturW95TGY22SSUajiXtDl4Hb9Xs+OKPqAf A+o/DrhmVdAV/vPTh2Up6RbsuMqygIfC4ixqToPKw9cGZl12z/Kqzpx8V0Ru k64kA4o5Xfpvp6Z4YvG4sWp7IEBAkZ/Kl/JTiN/udhBunxT34JXrc9nh44RH 010z23JTnAf/gVJgC1FRtqzrffhrqphw5/FrlhYcLHqj6p2cy18YNVRNo3ih mrOdFu5RrstMGrPPx8G6+aSSQk4JlSiNEpzRvvz4NC4lpxjZmPY15l4aw8Iy YPW47kE7HkP25QHwmO9hhMhe3gpLKs6vqpNVFVcXNtRWi5Ig5BEFM6onXtjr +V/1O/xXyi6QLxVfH+Y/lOMMnwqlNhPExbrGHiItYq8zB/XMzLxBm08WPiZw 8TGWmqiHl4WnLWn0jTzpJGXZaFkqol4WM4gNZt7wqIirznJi8XBvnhzmjhxG C7cebtCbVNJtWumHTkPNTlOMqnhCiMYCUqw+zq15r+EPCZ93ypg7pqutDJeB z1R/eWt0vhzxl0nSGwo4W4TG/DCGEWR48I+RyjXEBmegEG3Hx2v6KGllGUAL 0MkxTOv7frNpHXuaWYKyPbs7OVT12LYPwrfXzohvrtQ7jkqCQRdH30Q2r+YT vOLOfYfy3PPFZLJVI9++QhZvFOxg0+lubPVAdMX8Kwrp3vCOgYQiBVDVgVhr E81JNZQqT6tbfPhvrqOfckQhCqcHv2lNDckT5nAdNrR3fuoBFxNTNbMeDc2L bn25fO5ntK+rfLs6HgIA+X67/2zrPd93Xs4MN1s3wLmYO4Qwu6fPl5/dsKT8 EafF6ObgI4xtyL6AcYAqxo7v99w1Yyr6KW6qZh5owK8/em/beDc9D1e70f1K Nr+5fk/WFgAeGngu9K8/4dn5TsK09O75b5+z2aFmt4YGkCAkwmaNCbJ+B4/8 vO3ThmU2+GyHUotoESxUyKboVSZmp7K2SKYx86sgYw8B+Eu89vCFlA4Wc+5F m6DTuawozgDiieI8X4nLh5TIwIeW77eqM313t87Mw2TtPVUsPjlFGCQQQMlt /h7HXX5NX3+zv7yhXGqtvmsqPRGpWRIWMw3+H5nUwa0wk2V+P4fh8+PjOuH8 ly9XafPRIV/BDM0UzLC1B+LPkYlI9VKV8JRzZErJO1S7PBGyYtN6o+8QG6Ms dWd8ozFO3Ap5I4T1U3KB+5UtB3SO7JwgBiDg1Exz9Emb/Hndoo8+3bDIM3+z 7HKQ47PqqJBxRFG+WyDRRfvKwILmlCDeI9Z8Rxw+J9BdMYN50HgZtz/Y5y4e iRL9JKkz4h8zUUfGOs/bMeo2mNnoid7ueWkpKf2RsJjnpY9MNec4bedH9cNm dPoFeAUU+6M2trNix8s1xzhd+HifY07/0OWAx4P2j16/C7rLzQoPT851dWU7 M3peSm2plgURrxrAa2jzAlfyTO7j/x9Yxu9Nv4QEIQhk7tUKpEUJO7syQi/A VuNBqjZkK2CofZYPHJhgfFHqykYUCEXQQy99fZ6OP3/j9fPXKgWndbkMo/ve GWfWaFktj0MMG32T2NLULmxTvyk01Rtdi8jzHlqtv6XN1TYzWQgBjkmPdAi3 Rr3UsYNKeNRAyKjsVUjAdxuG7An2QbFq64PEuFIh3l6wPz88fymWkkhHzIdh Y8jcfbeSK0muOfZnF4kjTTo05tz0GbhZYqzMV+zMwLhNOY16Bwd2OSDXF2vH csqs3qfUE9m3EeYXtkaXNSMYoZIqZhNAnVwcKaibHdyYz3OK3lAKeIhFNwg5 4aEJcR4F8W6SJxquN6mbdVHGiAWsMH61VZEC3p3WkOi2OvYOa9WA0Zs2ivKy w+zwSKW2nGBsqeTRwvL4wkXK/l040BqMmgoD0oAN4g+6cmX6YmuIc5bcaR8i JdNewp/z2y7OVF3GWF+ouojeGJvHGb4h2xICMKlQqZElEbtmLbLqylASoPl7 oWbFOAtaLVKMKW8jdM9vQ/e5BQg482pMqmgLdIsh0QJb6TrOTDSDdfKNmU+6 G5uZkK7dOqtgxIb8fJgBEUNmm5fCNi53HXc47bdHCA1LUvYdQiiNOzsiG9Gc ISVg5I3rvJrzPkQb9kGT8wF51x2IeNkQvty308tclQr8EQ6W/HZEKPGEXHDU JvNSWFRHOg7+rnxH7/436oc7uasEUnQIbmgFED40LESIkPE+sbAtH1e32lPT g7B0/gPd0StQkgQmEJHT5q4eZFy7ezlXRLqLVT1aYZHGqCYYNhss4SJahlgo 8OYjUpc25w2KLDWFYeZKKBaBrhyvQDxiaIWgTfSnffSFnpDoAZLmnGZlrg43 Tw8jmxNERFxuRU26krTYowRChOpkx4HoMz/EopreAg+spNZZtLbSJ44Et5kw 0HD446DMcMJLFYodRTmGz8SGwm/ec852+uN9f7GBEzpf12K7zGIc4Uj0EJPr AHlnpynmdSQ2by436fdWMV9PTlWWaNHpviEmQaOOZodcgxHiiMmdJ2IJzp2M xxNjhsjPuCwavmd+vPXprrebBGyLmAGMt6RwzdEDNCd+/uVnabF1Kt3CARtP m7M92XPmtMg6I8Y+aEqMjoHhtVVEbWG3dt8c4hxwT3oPdxvOzvpHXrl8HudX 1xQfb54M+v522PGaJ83dq895xKBBLfcK/pmbPGUA2kXFm+pQYASYGSF16Run x4+we8+Csb4rLd78USyiDOfRH1rhMfRAUIQgSTMkqcy3i8iJ0Qeh9pfEmb+J DNpN7cD7eFSjF4OUsPvAOxpdjFpI2UyTSceRccb7NZXxKRz8s51s1iPD63iy EwwbaJdX9hho6pxOO6d74U9+Hu3r13RkXPSfPmOhQSIiIwRCHIfOrJzIUGGN BJHUooIaj5GKE8a3HN+pzerGu1+sh2g3qxtQkhAkwkzV5a7C72XFyLJfR3OX qn6+yptJVn6hmGRqEZNuoBdpYsAicfWukTWhJxdBlKFBsJUWHjgVI3cmd8W1 Uc5eY9/8Nal0yrMMEiQtvj+kHsdQ6RhCZc9XZUzumO82togSMWESEHcghRA7 /fytWcG28/z2v9s+vO1O6ANrNRdwgMlzleDUzhSIla//NBmhkooQg6KWCIoK iERo15ff6GTUUFimy3aUXx9XSUsvZ0tzctKTQSE2vjjPbaadm8rp2f/OSUyF TMC6m/xKJ/f+1lZTbu+39BXK/FtomNSNEI1JJJ0vEiXmoquz7YESFu1+ZSAY tWkIAcC4Z0tywhJBTb5iFZ/1P6Kmwu3SLVCI+paWEIMQJxOzY7o9FmaIVDlT cNQX3SKCUPCIbqYEdsj75Znjndx20kOvhM8E1AzrgXNriMF34Dh73s58HoAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8R8PyQAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHz/Pe1va vrWzvk/P8rfKmMuOUKyKSQCG2+Uj50aoHPQUCFxTazEQ1dT81WAf4uOv9A57 AxBkELwX2oZhtEzYfjs9WdhXYpCCJtpaNL7tDbw64Tn08b+yp7GFTXqC5XwT 0Q1kcuY6mAyI/BOj3/d9ZJO+piRZ9/2k/apJcnddDOQg7YaV6oyY/DpmrseX xcppoccVrHZ4A5jAyz0IB1mBWb9ur98sQ0Oko6hUypETI0WLQXZCBRw3ioEC SDLfPJ76GoSGjwR3gyt+m1HBnr4aur4dci/qp6pPHVlGSBNrCQ83C1OJhCGd Cc5y7WSNJa0QGqbQzFFcdkIJmoMeXArCHPMv5s201Emj88C0iViBAIQJkJmS FRcYrlpeVME+i+HTkGJ63+p675/6fZyyQOIKqILBgKIngZxh8u83v6QAIjH4 0RBgooonCwZ2mxKn7jfs+/yHGouYVUpnLNuwQWAyqQ+VkD/U49uVbY9drOPZ hgp+79DZ5022MpkDtC6dRfJqpRkJHTKfugw2pVd30f5l0Tc49tpTfdLF2vFG mIKUZDMF2nLtPe1tyk3hR4YW7HnZc5bh6YG1go500EsknKeYlKKaJ5TRzveT LjjcCmP666GfxuWIQLx/W9/Dth4VrscOO9cJKLMX74bYnLkcNmmzsNhBso33 49g5K6CDEHuc3otCtnHd3SU9ZKazncgc4mq2+KpopCEIQXRcL1Gii2r5/s83 zVGNY7ezlCBTH4JRtl8qU9iHewyH3t0z2IUeW0HMrB3WfS+dLDs9o5tLrpkt 4prAdwgwwJvMQMbXLK32JrrBnGBCEVDceES+RM1uREIOBlXTyt8VKOgwe102 ynxg8tN+JDnbmvIDc9oQPKxzLy8gVEaIKQ5H8X2H8DPDM+P0MvC+979n3s48 XK77GiIQjKmB6WPDpCof93CNR9ybabOswqu1Sa0FS1YoYvAVLuj3QbjwlLjb NlrLsigoF4rzzDR+MH71J/Ra++ZnMSkpuYlTb1j9j6ssbh+5xnRKm1UNRsod 0kkOXd+ez3Grr3d8tMG7bWxbwyoahgYl0DZboFIO7FV3Qq9r28qKIyAY/gM/ zH8hPhTnnmYlqEsqTy0kYNNiU4swVSaLRQ/VtzsmVcigPgrJN4EKbwbTWteC FGyk/GVLBbfmuePZ/P056+IwySSRq6Nt+hYGiVqcExonBMx7ansc9CKaMMgE i5LX0PWI1hQ2Xj36lwkhGSEKNxALnp/HxdZSD15fGyn24DsdFr3jWZqMOH6U R10PrAJXaXbaiG1i8eGXefjTN8q81v0o6nNDM3Nki7nJZFucftlo6V1q7t9s bCP6jjjfWTto9unp2Ha27iypYM0YDjBXfEZhpDls6SOVyMqtXtrLaTtVyh28 dfHNX2ToMu/6Mw3c23+FGIbfriNpK8tvXpJm85faXPJugR1ko/85YNDZjA63 cdD+VrI7m4aaFxpkU6SNR7e3kXlDr6oNnhpJHdCUs5wO8D5eJ/WD4qV5Az/k Q3dmh75mhpyN1W+H6CreiLJMqr4EDfTr5PshPWZm7ntKLChiulyDCER5PDRw t6XLSvJSawvxqpOYBjzZXTwxjGeGV17UyHnZoJnQ6Z+OLg1Isd6hSaJ1IIXd FcQJvdVrI7yrCA5dbecLWMI7LwiCEj8RM8u+vfnL+lDgLpPkZGGZupXhHaDz RzLqdEovD6YdCLpyfOa5lpywrGtVv2Qsfiq/mRCcDbCE0YYOb7cwpi62EOai o5391tLQlrHMAs3XeVgO6QQZAbEPjwa5MGReWsMFFBhvukliTmIQiIjFbPHv zjY/VhMXjmCqEFhzfvP5+dDd0H5Q+c8p6SsPtEOyQiaSBwmkNzu/hIJlPo/4 fL1wS3BEPUqPutPZ/Zip+/99Py/QL2aD0eHXlxA9Lf0f2VLbKKIDORQGisXH w/6bqspt5S92/DwYniQfcgUsTATn1Hrx86N0wKEDHj22OEAcd2A86GlZMSGy O726zZubL242x+r5+X0ylaLz6zq8W+VChqdoNG19a9qdNsRLHAhy04HKEIEI ED/aubBMQj1oYcYLBAx9O/u+XCkkiBIpIKfbiAGVCFk28laltS0y1d3d1uiC 6rXVN1u2IrptunbTqS9LyR5bbVtq1CVsCskikLbILIVFomabUlEoYuW1dTZY ruu1kzlw1c7buzN0WYl3QSuddou7juHbnKud1tQbStKlrQoEKI+VlA+RkNZp q+bBV5GvLN5wOwBghssDdLtzO7MHCx68S6u4IA8676T/3b/vfXvfEWVB0EHV 2nMsAd8XEkYyCGhC3p/j/vgamI5kH6jWYgXvX+wrmGMdqQrCaQIm8RqQHOfs LJfeU4sNUZEqAWiSA2GDiM+KUV8VtRV9EpNvjxNslURoNploTUbUiaxVGLEV oqK14tctWvJc2krEajaxVee63bwXwmuVoTbSaNQBoNYtEW9ez3UAhDowUDxC MnpbVbSrFtLbVtuyRsJm7q69dyTwXTLnXCtpSKDWhllK7egk7ZSjAG2fv9eu VPFIcxYjAywD7WAd4kNqowo7HnSFVAAQiJOTnazh3CP8UpIoJCw4ZJo4JZ3M OMSoiMJIru5ypNKeiRA0gbRdJdIBUAvJpmyqJvDTFMpZFCVg+NMFQ7y9wLII IDFiGQ0MOaGOnFzqqrnezSsqa9S8YbV1lMXCmJivDq3TpXRprc8tQ699BUC8 VN9xKTsEByx72IaJ2KHlBSHftqN318jWRIbjCeKQ0y6sBQNJRYIAIcBaMPF0 DJAx7kOoCSCCNIyyZzsqDaKSsrD1QxChKMk7xJSMnZFUFFFOA8DnkkPCBwFI HCS9KBOYeRWckslLaCQ4Q7N7ClCmt7661voqb3t6lTjq2xODFHMADJEVC4xT SkaokoWgFhMhEwWF3SySmbGY/4J+zt8c6AMYgdCUgghZD7UJ4+XiId5pbM8l fwauSr4q+CFHCHXBUbLWP3CFdggvzIh7Hv5h8jEuyxhfjfi1rU9WWn3nkxP+ jg7n9jv8Y50m1dAONoeW8gfytre3yhRbA8O/P2/faS9WaXKnlnynp2eQ5wqP p6IQHGPMFjfttNGh+70f19vw59KvEqiw8N4YiAaGrqh7l/BR/R+VjaGhoaFu hkU3OvqO7jj9MIms3b+xtXphH53uJKH9fkwwbyBI4G8ix2h30rUQaIx8UBzs Iaj+a8kMOvGfi5UfXTXn9fY6/cUsiMEUUUfshAphgXZTJm0vku11Sk2k0/0d W1zDUCnh+OzrTA/qt538R9WwHITfrNNy5BMXx+gQZ+1/9wRX8P3ESKVvpiIW +2pCBNxsn23/yRCMLoQCOicp/pkfSmIq/aEkWCY/gR/MRFLHyx2kAM2teBHE h+tDMr/qg3j6UnsVi3MzuYHdJ2AXuvQhIAwiqosirREVCiCJsiII1EsHvafk kIJfKhCoNiKIliLnHP1B2mwomAwmke0x9FJMA1GdO8QiRvIG2gDhoLLPfwaY UhSOzBWbXOlAHSJkI0h+8hRESbvWwYes5znnCiEiSIc4URIgwBh88dM76Cmh GJGRL3sNhPKCDvp7u2udAAq7w3waaFKwBYD1pIdZxq/n8TFQL6ygNeK0oEih DKhCjoPpo0c7wYZhwEBSBEZ5XlKOExk8etCBkgOP5mYNXs/0/j/44/1+Hm/V 8If2/L+sD/qH9KaFfXfPyc1eMH/2n+6PyVq8VBb+y2V5bdhlTaSof0Pqy/z0 /1+mqOuurfPQpNUHnOubfh/bfmYkCosKDLzuxKzXsjkbc+H9pNatKr4SVm85 hy5uAi+EMHz5VXXW1y3yU5V81cVlRDN3/ubP9LrsZwtxxmRkSQc3Ehmf9HSb TEkRKTaRIHObC+jdjpKtIynjEj0Z5cI70Z1c8+Rqy+Ho8vl73PXF4xc/QQfr wNRQ83SF8xVRTU9Fj0FFN0/jNqfG/8EeVjsrb0MrEexD2/NH7ZUgrUH6E3UV 1rnGUXTrFc/ztvwxj7flWv8z+mc//B/PHfvzZ07XDzMmb51+VE51aodrISdp fF3OSC22HFHy835QJ6xWdCeLGqnWS9zdNl5St70sONW/RRUxYHEdfK/ieor8 hGjPSsgobIjR8Vu/Pj4c8Kqk0Fvktt1Owk7BDLg5b+OdjVUhgIKNqrEkjnJw UPhMGgmbo0gwkzNy6PXPx1nyPrfpQJZM/a8LEN1rs2+g36g8vKiuOO0uT+NN obecRxt6O+E9X4aKs4uWuOiCSMnng6d4sQd/Xn2fJfN802+jv81Pk4Lq+iuv 3XeaGktz4+Pd3ey8Pb5Gbu2H9Wh+X+jj6ePkawKr3T6uDDiIYMJIBi6WqyaE V0ZogS3wLgSHeftcYJ9IV+w2A/rsVd+uTUlRJtG2na7XIJ24DUNB5fqkYdiR GgwJRXc48ZN7zNu0I+Qq9p+PNkbD/yaj+x1O0Z7ez3fYe47ePUP0IgszUfee HxeePbQ/98jv499R4i4+7IgYHoPtaispIGZgRDcgwOcEEkneHcYO4LNyjoSQ fE3Njk7zRaLPD1zKNl/3Y7SZka9yJNcaUThFVFOq2UPxeEdp7CwlRtqjA++O u1BPcfhVNYcSJrNRAbIvFpqIVbHiSPwsqoz3YS2QiVwXPAGPC1sWtZMhQ5MO I8Dn4iIsTI2t9z7OALQXRsZNISIX/YUjZgkgwJJQYkMisrmHai5mNdL1n2ew 8h6/TV+m/9Hj3+/3+fV/HxnN+Y3sESP8f3zmvUecZNBul2qbudhsFq/NtWP+ ycNuJUfVSJXUUciBBmMLyeyHwJyYIdVFNV2a+z6BMxcbTIypDsH6jTyrM1E7 2fx2DSrO653uG+r4z1l2zu3HX4LtnqOlOcHrvf8Kq9dEpV9UKPD1Qtbp07fG 32s/ZJmV/MXgcNOTkD8pesp7df5e87TrLBffpdkMj1nbCDMGYfbFtTqCzJff CNBGMlHt+PM5+r9FHrqqqXfIeM0e47pBKLUJF8O/B5KSdxtrHmGdymSCX2u3 qzJ+T5+qui8RDaWViZg8LNuTSFGvP+ypKfs48CY9hTJ3jU0tnG7Qh/bgfgxs 8wrls56R0IEiG/S7xua/yPjtfEgff4BREq/j7cmH6+ZHzxVVV5cu865UTVEE 0jGejh8LZ5Uf4n9PcaPYBwQ7A4g/a2+F1cfm4xs+74Q8Wxymj9Fbu+UyXj7Y qHoKvu+lRhSsfVkReH21H18P2bGY4gMWI9/CxjaxNjtG6QcOIbNqS6KgSsWI cwbGmaN6JyD5GoGkhIDEiJBGAfhBCUiEDmgBgDkGAhMzITACBBVYqkeFn2ix rTy7uy+PYfS3k9x1QY+leVN40wk6OGx4pvAmbzwpUJ8vNR5rpJrrIVzH89Mo KV3bFo0r5Q1wKYSWADOgf+CrgyJQC6G3s8ksacfxUY/PqMN9pNLOmmskqMLr 90KuyPNmeQ7KYlpy+K+Y/v4Kjp8D+ID8ZoIdP7ScCjEVGP81qDAFfoZrdsW+ 277+a6b6VNrv/PGCqLUmjheyDIjIJpi3jCMPtGR/kfLovSeWjEn2x/sp4+s0 f7i2eSdASIgI9mmbWPxwP+7PQnEDVE4ETAMB0noRD/8ZCGzjwMmSU49PKG3V JUpGkiv+IrKnH0b/yzXQ/zgCg0B+QKVGgaQRIMoFBoseu75d58YMDDH23W+q xgYYpPGmGpAnjleQoGBxeX9ksoD931cywga4CB8IgEgPYAeLUIERO+0Z8Lct jD9iVJ/nlD/pqsOLUYCbGmy/w67ZtTGxSkqa9uurbSKS17ruhb2u4pv7G8a3 lllSGSkwExCZij3Lob27pGyGZER4tzTN/6XIspSgssVUaEhotpJIwDIkU0pT GkZBMX3O1tV8VS1TLVsaq+WKvZz6hZVXfEce5n2bCrlKiCVFfX8WNih8NtnQ w1z+goPkYOy+TuqW/8sCIfWDgH7QSP0SaF7tz99tTmoRB9f09+N/3FJb9fsd jUcW7vtNnH+p931kayOsM9xyGZuHACzAoxhnyFzi55pc3GiBS1ND2+chZ8T+ m+quaJw6Omz+W6JRPFAip6MnZLlCXI3P9X4yNeSvubkVHudvNiengPwGjt61 gwCZtjedjz8LjBShhgrsvo/aG5PsJv7ltcg/evYt68BvVNgbQbYsoXn4VY9s Ao/YTG40b9G5dBc6atYcS7CGgYBmMQAK93CWpmHPy9yPz7v3R6e9U0jDi8NM pwJShE6xmjBC1ZGQJJxppE8vrSc1qmjDTjM6Hou7jFZhi3JjFUTLXDsDzecX YxM5bMs1TJeKq3pNKudQzYxmGlDziJl2pGowoWB5l5U296RWMkZLWtRi1S1n WmKeZzjMxT6w+bylBDkMpeLucmoswgd1kjN3VZnOrU4xmRPp7vEZwSjA+Xty 8zopRC1q2xoHm5TwWzYh7ijWGac3mRrnNNDu2a1lXOcYcjU4jOcZuiijWWi0 XhsUYWCbTErED0tM0M5i+QPd81+XW7vEGIYDGDjSCRrCfVfEgBRRzQAG9AA/ wUiKgQYqqPlAEFqApCKKk/BcuAT9rCSH6CWIwE/vtBiohIQYIKTJJAJ9Icvq efMsK0RHGiiStGEy5giT8jNaKVCjAqsVbFudKT0pLkkm1w6lJqqGJhmLgswU ZCoYttYpg1zJ2vHSrgABHROAAAAHTkbdOXXnbpu67uuk2TySb7htcZ5E2ycq 6evLgAA4W5hNeTl03N113gFg4VPshSYrMHXOAfkQPq7O+XY/D3/riQgGiBEE SIc8q0oIkRLiJ9msZ9QgkJgCPKkPXOflQI8iIBbhgWlNHlEDoCCJAQv/MoDj BQLQR/P/qIfMIc1O5EmBSCHKhwQtEGIjFQjBtK+6Gt1Yma0rNttibNoWlDFh FO0ERK84P+gsNP4UUavo+xzvZgYicXNgLfsifmvmyfjH5EgRMolH9VjeNPtc GpmO0vUhw4TweHaqAjZAQVYd8WastYByBjS7yOcCwJzhrLCeYNRSo2KoFuwM CYIUb2FgeTz+aWGEyddaOCAewmM/fCJgjhg3x5yW9DDlE0OsoqcjnSo5EvBF CgqDTDYKdoj/XoXOtxPwlzXkkbMGePOu9iAa+cvyJNMBSTu998VYExb4YTf4 rbQky5oLe5IT08PJhBKCqYHbifvZvp17csnfp4Hzfw5cmJat+8HU0ijEeIWd L5EA+KoNDwIHkzzC9ccC40Amj3thIT4iAyRWRWEpVDeIgMPEVA+O5whbzlN7 N4GL+Ko+CMReJCH+C+MSzpxKH3uY+qIgpzdaeNfCoeXuRQ747oqaUy0pvrE0 IWJhe8c4R4PNPd1tQ5CB2Q67vf9WVzzusrOWrtk1bMnXtWIO/u52Mw4xPjM8 vjYfYvTyjU5y0rq7WJh/Lp05qs+GtWtovntmdJ76XBflfOr8sHM+S/j01jyI ydd0RD5SMTmd0dcZzy8aXG7pdud1tz3fXxzoXc613ZyqxolpXO+Wed2MPCUC brGTsCYg7TZ9xoKG9xzZCAZHaFxDHZgUzh4zhzFRETeXwYswkrq2lPJL9/d4 d6LALHYKSpfhzs3NqmY2Q+F+XeiCJQuCYQ2ZrduwVDTUMA6dawWyfqiEQaAT TcFyPXMg0xmTcE29bto/eDIrrA6JZMR6U+zW1nDvhmXVyMxpHfzcUSyCJPbv r2Lr3WANyzT0LBZS31H4SRE2iRQgsOae9khWPKgH3QZCbttsMQxiw4Rhcpl1 g91NKHJvCT5HLRz2bQ1czQqRBQvFmObcLQpknSQD7z/1H4OjK3fB7PsL16ri oou7kixg5ZWQKKiimPpqr3HF4TuymkPrU/u0UJimTBvRSmZpIapCAETgn/24 Z69+PYifP/N6+ftOnr1guPYur566Pl4l+Xfm9epyoilhSM7CZpTHc/Cv8/GL 3wOcrid/pLIfqKOPOJy1YuosGBPEbTSo0/Xoffm+NYwls+1unfHK+3tZ1wY7 adStdt5FraHMD2K526SHqkwwTXEkzfr87TtoQlTkRGehWMzQD3xb60yvCZ7i ZCSDQqHJH5e+ikYbJIJLQDomMly38VD2kAwAQf/Dinb5HY2P78eZC0SSEk3W R8YMCUQPt/I/gCCJSoIn4n9OgftR2O5PQhIQjCPX3fb5d0nkHIjkaxEN0vdU EZV0HMcKmGgHzkPaWrw8z7ZcZTjPZQ1YFdJ0fsif/vWf2L2DMO/yJeHBSlsO E+E9eNEqCuP02026W++tD5xiH0++rOqKUcEKrE/+Ywa7/6fsfG2yo9+1gYeR H09qzyKc9VL4mTHuZCzTOGqpl56L4thI841ZkDUCXe7gmPPF6DhdG+BKcx2Y dOXUsbBk/sOdfsJCX8cN5f1J2W/inJeqmHKmpmYho/qN7vBg+qDLL/TrH+0l +FlIvTd5jMg9OtjaIb8d+MIJdClwMpbD4Kl5JPepv2XTGNsZzmM5jOc79nPD n6z9levzNJJNkPsEET6B9vol+7WAgnqx2pAJAW48Q2FzUtWqsQ0DxjmkadSz MDger4jZ291fbzRzjWqRubg8MMXgMximohwshymTFk9+PplXVxvnBL8/F+xK c1l+/1689+PDY66IxB0UPF9+992J8o0ke+t6BBFJeZ5KLedB5KXbYrr8r7Vh jXCyrVrepVLXsyyunhAodQtRFQRtxeFbukyJpnxcHRBx0IEkoTdYcSFu4ecP 5LhEZfzjrqo/PGYx7o8/Py4nsz0usxlCFHUgpv01/8Y167NuvHSzPzUZ048c o7rJ3rPCiOuXNvFS63KjVVZuquWdS17a9d2WzZcXq6s5jDXjTO+X24Wca+WV mb6fu0+x73vu8tr9Nu3icL08OKnWpfn129bu+uyzso8rrZc6w2c+qXRYQKT8 ediKMSh0mMb6ZIXl18yp1751IsQlXRHHbvpopQWcX2qKCuQ/J9uUd2McasZ9 BfHKFObwpWEqroXQlajLGuy2U6K+/PbTwONV9vLPlTjpweGL2bHpy0v55xS6 bZ1FlG+zwusJzdet8D7TkSxjaX90ecTi41w3b67J08oUSv55lpyuenZx0xv3 XY9fDU//F2qFE6ezNdflfJX03UF9z47aNsBUyddXM+2q3reiPDBP09PV1Zcu NGk92PRw175y1LPosVsZSe96rtUOjKXNhfKh+Ec6NcXuqffVPdPC6GhZVdjS rbLa8Z4Zwt5nlIhuu36plEYvGJulpaWa0Pwm+c31SNVFFtM+Fucrrpxq1qT6 Z4S1wnt1woozu0wpVthpdnCy+3dnCV1MY3asrs5ar6rIbtltNGyzlnc/Rb0Q wnTspm+ro53yV9eao17NeL7HlfLUzu+b1boyoq2vRCogXOrdIRufbr5oSME7 12cpENcKIzoyRjhx5WFFGL9RjXyhXZjsvdGxqdcZqFk2nxk9sdsYr1Rnggn3 4k+bhBFZvgktcT4E8HE9VTKLdB1A0qap2V04QeCXSa999XXTlZmtUbOuO/Af Vtthlx1OmosNVRHjTOK1a7aFPtoiWRMbY9E+rOGrOUzbCsttkZpXzjlY9d12 eEcrcbI1xfC6mcjdPKJjhXO8zNtiuLGtoqHo2SKSNumkSgorNCZphxw5pFZS bHLy8kYTkHaz0PNryV6+MmByj1Nz0NiCzrwa3+NM5BAgljLqRPnsMSJcZG4u pwMcZ0YDltDUleI5xmcLnpqOmxswaPHsR2DA54CGcgR2OznO3KwEmCoNEXzc rz2qoU+JXYY78CEG2Ocxuw7o3YGLBCAxLETkRMrigojEtw33xYncSKAiajMe 8yHKenOuvb1NtjL6Og+YOemyNVzt1zCoQbnsI9SDQiS12jJ+KxJmsrKRzDkP WzXzLLQsHMBMWECIIPEQjBgNzigN5dHwHPTSkWndpRyIcI2fOynf2kqeM/Ds 4UU25JwQihwQhG4ekU6stLbC0rOI5DMtqs3aRpqwOYpKzIjhFp51GBgFWc4G BQr2g2dZU1ZMyey+l1cIL8NmBEiaFDigFoTtoNZJrgxEFBA5QfAWd8LLMrr8 yOyi/OeV1rZFGZiFNJdjdBXmBnBRpurOeMeGdEXRvbTQxpehzqiPc0SweDIK DiSMjIxDmIjjahzPK4sNRYUmrToL6DHWUDkyIVkC05iZImSL4mSzyecMqd0j O9+eSn5HEzdzaPqPY6lu4d6jK0OnRtnHjJMWzL4oyZzAqM+TsVHVG+njufEt k5iZU3ko27MqyskbBBu3kfEz2z01u3A/DkGxB55dueTL8ye84CRM5tjXNLSX eUa5neCc8B1sIQyDb9jat9WRtuEa8oxuzm/GMq+VUa08+M4E+E7qsLad1Rhx o5LjlbSuRCps+iIh82vJhHT34x1wiHKJnPZ9f8AwX5cfT3BAMbndySx1MntB vMpQM7pSw45LOObdjlEn2L36NLK3I7/c+ncaoh1D4N+kkPfe5GbP6D39oH27 LCQRTesAyHghjk7MGCGAUM+o2nlIsctDGHhkdgk+wWehIWVLXNx9O+KfV0kF 2n3x+cD4Ax+r9X+DyiDcT2ddwxctaBvVo7CSgO2sereS6vnS8PK0P63B4QKK EvvuZpQ2t2d/Q/zFuvy+pU+Z7L+2qB3rSYqnaUG2N/w75zy9/t/GLOj1Fx57 zfj3d/jzj9u2t674qlRoU3a8VXjXo9F1tSp126a3aFkX8Svrqrpv143252Y2 merN6K8LY0WkSdcX137J3TnjqthTeW3VurmzwttyusClJJXTT600NHaV1l+k sZ2yqosMpvU+WKlTRpHO5vX7Hbcrsr9V+U7ieM7rYPffBYZ7rIJYZbNWyvds NLo0WGuMVCzKzLVOZZTDXqU9e2dWt3utota+y+mxQ1V1nTyfJa6Xsxvvxptp 0nHB5Zwet5YaGW7VCcbbuG+ENqL4VYbtV9xSp0YJ4UzJ1YJ56FOlE5RlVpRX S8LcFVq1aq863tDUoIN3DGAWlLs6a2lw4ImRtuysk945Vjuwnqnfsd7sasPp XCnS6uvPO+q+q2nZOOby2wet5Z7DVu1wnG27hvhDai+FWHDVfcUqeOqeM2Xr qnvwM+GLqa14Y2y8cdVrx8fHbv2fgPFQg37cYBaUuzpraXDgiZG27KyT3jlW O7Ceqd+x3uxqw+o35qqqqrhb88khKwIVh/ifYbN6sGNyuBAVb0xyJkwLcUAj DFMeTouxSSSSUREeg0buTvPsPpPdNjDXbiqKs/gQ7wZAZhmgpAgGsY4l8SJl McSSA6lHzq4+JCgeAMhsVZO5FKdYKIssnze29rSqltKkIaEPGE5ww9QGSk9h khTbUmcSJh1WBAsMPTqYuCTdadh0xMKGEVMeXXr5fX3Pur3/VJJAkkAJJACS SSQAkAJAAAkkkkkkCSSSSSQAkAJJJP+HcSBIEgSBIEgSBJIEgAEgSAASSSBJ JIEgoiqiPjt4DgOgeHdoNBH5ML9IyfZ5nlea+q2+xvk75flJJJJJJJJAkCQJ JPfdwEkkkkkgBJIEkgSAqiIiI+z4+oAvqYcuR6+6NDY4njpkK13oyGQ/dSFB HtE32lSEkPce8EdAuN/tofDd5xQOkbjy6ydLD1zOfTTJLg/UO6qiQ8ShUOmM AiDA7g9dO8POeBQvZ7Nah1Ju+RE3u1vlTkidvBpfUBCoEEtg5HEMBHEO4g8k 4VsH8Pj3hccTugrscq/MqqhDpPWeqnNWpo6kPMZJKTfj1DARnhrmvqO29N1r M1mZqhHQiKqqqtNXcBJ1znO4c6SSc6SUlq0Bo0g0aQtWk8w4hZA908OM7IKD y4TEMxuC4Q3ir7/m8fVUREEREREKIotp+xMHt12HKJBFg4HOgQRAzfAZAGA6 h4+a9LVsGjc2UerwIqknf7A3AzIhxmMhzgaD5mEThXMfQl1Nod/EO+xsbg7G pDdatz6BTGoDEOfKIcKhoIHgD8kw1/TZYplABY4JUMOZvuEkkMQYvLb8s4Yx 0rvZj4Bs7whIHLMUONHseeN+SaWgF/X6/H8kiyCJIJNkMxPafSjFnrHxhUJ9 muOL2pYwMRvUhciv8mOWZA1AFhy10MvOfu7ydOn3JsH2gCAZf5X/gB/tkax1 1rS6TFVD1wz0cgXc3Qll3EkwgMDuJApdJsFVmM5JMthINnIChJP4iRw0czkG jAvqyaxdK3HMMqihpFcQS0BEDQTmLQcBMJwIJmfqNCHPKG++QUA3NcAQmoNo pG2N4HElob3ETv5MoQplEGEgXlQADIikA4tCAKIzPPMA2DJzIcZyMgd2UylM 5u8upgHIgaDZ/XKE7cFkjFYBhEMHXZPz3Ph+L14XRBvWNdtrqglr+tfNh4PX icoWiml1wJYvaml2tXWWqpIfln3wEyJkpjEtsn8yadW3+/9WWnzm/Mzz0mm6 J8+Je9efum5qmoZAFvVe/smZgpIug00UZ3sBZCMYjBjjJjPJ0Mxuq46t0aRa 5blLuCZF8qmHG372bDL0/X7pP1zxiZf90fD6FXn6Gds2klJDLtU5MVNwbxzS 8APz8fo48tHx/vPpOtXWkAPDHLZKIQhwPmPnSI2zMNIABsiyMses1gFXW6ks hhiRh8b4l+KWGr/q8j+vu16wkVOWoFME141Nb/3n32P6vy/02HDHgZk2SBRC k23IyQ8is6GFYEcN3xDxFtVVYwmAcowteQJXNt+nxvo0KVRKHA15FTVq/F9Q DI6PQa15zmjZpNRtzU+rNgTYh9hD7U8b3gAFtpntzTn8CQzA2ihwfie78zZ/ acZJ4ez+tSMTkMoKZ4/JAVXVhQK4LV0qM0CEDKDDsYmQHfml8z0lxkdadZrh 4p9/5Gppm2J04+eDszDfz/sISQlZE8v/VrMFh+Eq6/mvylIlBETZim8m0rtX jRhtcq9sF16WXvqnS7gzvcx4nEnm+xhgYYvYrBgYY7Zeqv5nvjhZHpoIQ9u6 DV+orNDy5nboZ3Yqr9oHlPtjAuenmt+2LEfZFMfbE0KL65qUgKAf46AhXufU HfI/RQ24GzwDrYkehzHqFrqWvo5PCUSHd/dr7G92zvDYuEGCD9JTZW5QP5fL XKoatMVjgMqIpIRtDzcuN52O4c7igbwTdpC2ZH9p4EIHHGiZGfoMZRt/jLaf 0y2K+ejFbflrf8J6HRjDaNMO7Z6LSBXPywaNm5gnYX0S7poqCUQRdDRshbE9 zPFDn1rEDRbJdUQwwyw386f98IeIY3fD6er8Bn5KlefkQhCEk9g/XhBOAuTT md3mzzQ9nmXzoE2ej1OTjvg5IyM5JViqzMEur4ec4optq323bXviQFLng6TT mOoYGx6DCdEPuP0+fIQRPyb/h+G9r6aJZkgKCeXcfJOtcTp0PMg3Qoamhmck UKiDFAhpt5feT+j9x8CGoopGSsuQohg90S8AmQ3j2mlGGDI1jZ9PXDuplMV8 vEQCyH27eEA2ilzGoiOyFSRkEqKXsbNfdw7iT9lgG/hbYIF0uxaVARYI6BeD pppgSJs5omSExSQ4fR6jsg0hJ9c+a7gcLYRIiB4Poh+5ytlUVURMW8/j4rxN JfeOTKmBEfy+k9frHvRnKl5zDu7zMzMzMk1Adf/fnsjt/bUjHPy9ekZtVQqj 5ZCBMEppo66KfnJBiMi1E27f/X4eQrm1qcfrGgzouQPGrznrO71iEklqmhil u4VKO+FqfJyCuSUUUeLb7Oc7xbRcyOkzLu4sFhgNVS7Q9pFlQUtsVG+XI8uh nGhjoDEgKANoLGplgg6eYhYr4rhvInymNh5flkRRfGI5u5JPvBgYYi1hac22 8xZ0O0MH+8ejsRRXdzCbjcIaAx+Htwbp74Bhp0Pv84mG4iX934+DfkCvTjrb cMKYaPZCVIEnsfRmOZrWa8Xbn6XsyTdweJTZK0Hih05snhxwVn9ZON0YdxDD JNBFFKpBkIZoUjdfwHoJnouK9lksspOXxHYTaUvL0VTsQsx+gb/4JNRP5Tn9 1zNN7jTZIUhJIgPHbt9QGV9iEzMD4z5+17Wv6dGTnH2O0bWa7Nm/v7qSrs+f 5qilujmvCogQ2chMcBkjfnQxeDCinVlGRW22GBfPs67QKztu7ZeOReVlYSst t5UKx4qd3ocj09/v8adsPtwzw0OOQk71U8UrmTeJMTZdSzQzS5EFQOy3wbk3 E9s7vy7qW2bb2LnM4XffhDOb492Dn0594g3u3Segnd+WZ5SHq45evq1mCESv HTdMurXWsdT4WzOmYp9s/3uH9/ePLX27m57KOVu0eKdeZ2jOsesub3rw5yDk UMNWsvGFL7zLEmmvcZxJjyuDmJ8TITJr/skbF/MLBh0kAekTDB8PYDl9SV2i EyzJCVjaMo8NhuopS+PQCokrikFCFpzqc9VdFIEYIHU4knDy7M1dU+Px1mHc RMU0zDu20QU842dDGN+TLubf03lBlMBT0+g8zHpokMLJN55kxi+IbKBiu9wz TskoQcyimHd2/t9J+v8uiH0eLtg0/j8p/Z8Bz7I+l19HlSk8lP6qIxvKMGiu N1mNtKVcqvL6/RIimUC6t/N7o/DLKirC/ACSP2wQoqXdu89oPsRr+fdftk48 2xX+DrEdE+dZgjEUU+MSePBrGMk+hcDmDKHZAJMzGE4jGD4BDMOmahBgKCVK evZrgKvVTaZJXb4WPrfLmrbSVeeVstVASIJIzQ8tCZcTzjOi8lKtY5lGUfzl NQWGdd7WV8qnzvz41VUVF2WL0vCijVNrY6stsoW3l6DCCkXXFWo/ZZTajnuL CJGx4vgzOO1CwzWuCUiieOMs5atxs/kbT0gfRMb+jUu0HdQaCYOwY+hHf3sx 4vD3eyEoSlOBNqKYha+CyEiIXijSqv7Myr1cBqDXP8iVINgGGpLWmZ9M45Nv U07NFSOReIjJFSOjQrvDTm7zLMjKuGB0A0pgUCyxTmpMaupYM2CIvCd5fTVG JhiTEXGb0qIUinT5Crh8GXjJlUKSiEBidOPnWgnVDwnrEto1NyqmYpQXrT3q 8yU5RpjIF4nJvRp/v/Z7P8Eo1qqJ/WkmZ/xcQ/3tgIKqMGatykCn91AGlgFp UNKMlaNkz11y6bpwpFNXNula/jef4n+Pe0etyp7u10st5N1o2KIJEtkp71yl GIzPZVwng5MO7ty7eTd4d0pNS5zjq5jTTBzXaWTEyYl3XZTSkuWurIkClLzt y+l67Xhh66O7rpYEFkkhCxAzFjzu7ndd26UxZFHddIhqVPHLlzKlRgrGwZoz nWLFGIokVUQrVijIYl+QfFfrT9D/5cEuj9f8mGngfb6qOyvwkw9JWpjQCS8N YJP5jyzTEB5PcJoKyx/U9MpSh0vTld6rSMMq7LGFCFWCAz9GkKUY5u1V1GUh 14rnT/6tY/Z/8955sNk6KTSiEFo8ocPuF12fuxRykiJIiS/htfr2xrisHaK6 wOO3XndvKycRKaM5TxinFDpHbDkLnf7o4v2x600Y/P29e5u4SHViJ3PeoG09 MLf7Sxh40Q430F+xTj8cn1Q/+fhhxVZQmzK9X5vAlRRCBrtKbsfVTqrVJcVg Wbs3twugTrHcnVROn5Y0JBq7LI5L/XuctF9EjIheWGOp7W337MBojEa8Q1ZV bx016RN00aKLRZoKC5x0NHdn/x+ujifxBdUkRj0CgqMWHdP3GqrkiYT9ukpE PvSFv4lcL7TVo2iqr7yVn+Hq8mi/ddiGFAUFB2jFSZpmjCgqIhIfoYXdIaUy qRwrBYkKkFlK3IpXdXao5G12bup9usV7OBsGyMYyVlFg61HGbwwDEZKoJKYW FQypZKDi7NoIsNADuw8IlE0/5Y9/PNF5BZUFSYIiipEQRI0JSjNL9H8/9B8f uvdIw2kNJGX0/h18JS9XaJXLdtjJGc53dMGd2jmGsrnNKFbaQhkKX03kvGIS xGCi211hcDlYUYx7h0OKxzM8kZETUmpNK7NW4pucpp3dMTJQpIl51zCnnV2I kwqa7unddEZQQ6veu8MMiW67sSMSV3W6YhLt3NE7rmricuO4pdnRIxe/ae7z mMmZkKB613CTCygmVk2os7tuS7r4leIJlUaMjIeF2506vMerN7jFIyCiMOdp g1QGCrhGoyUlrbERNh6XCTfeN/T1Zfs/G/9THjS/3/YwFZeiIzwcDtYTID7j 1Xfx/rxVf7z2WgzNtTIbBj5v1KggEj9ml6OH0zPKf4HuBv4LztX07VfZX2KK aGkpko3imTfVt/9/YeemZVUVMkMNzjCEBtPl9PpGl6PQFhE9/m9fpVb0qlpt VZqmGTJqaigdUiKwCgFWkGiEEWBCCjZWBoAVf5AKtkBuKGsipIv3g8b831n9 5PyRKdULmS0fn/8fqOMuzYG0v+VmcGCeQ/4/MktqyNPrpP9/c6B/bLvsApgT Eb1efS00fKJ5oRjAM9wH40ajIPBqnAYE6RVGRUGMAiRBCjMiaTHAxG5+qkRv Fv1R2svsX126hYMWRLp2khsa0GQ3OgmH8kPGtQ8Xt0gQga9G5QhE8budBrkj WmUIGTkZNixDXy39nYF0q96ugfyNA8E5NLxRUTYCG6FmwLvvv58BqBno8AVi GcMP1nZCGBiuxfmCaY89xKDcJvXMoVMl9fZIjDtyh1eJGZ2OVBw1xDxMC5A9 AywnSL0gIUbSkmm1kLgF7UQO2PAD9MBgc1+tAwv7wRa4gcdhrm1dgYSmZm33 30/6gmV8u03X2HAKTlt84KahMhMFMoGQ7w50B3FyCdo4j39LAVNhj2Zm62wT c61LXNxkU2DTshycDFAIYyZ3SrUxIQJi+pD00lxdxcyZtSBwk7Medj0R3rQq Lkm6LISKEzAbnOKS6klQbG05pjwXzg6weWlsNTb0bNTHcxuhEVWQRiRigLBT pyn0fAOxyPh6+cOfeV1UIgVSVDQtY9/s7OHdXiRCHDhv6XPVvl2F7ygLzYf6 c0IEmToMiEHGIVaiFFksug2B0gy5CSbhxiB4ZA6HANxLFhHBzfOI29hXR98N d9DxtAqqYYQN2e4pKp8MwDIV4bhsMj76e8dAN0HSUsjShticb6zAH3fZmCWQ VgkSQBAkGDGAREUxj2srciCuQ/Vbl8ZLnvZjRg0I8G8vEdsXfGAImVMjoBEg +/pFxIMfVfqtKk3foBnafmG8VQ6YxAGA+ao9xpMx8TvwZo+F5Yb/yQIEzdl1 JoWsxo0OvKT6UZL+ebXawr9UwHnZ6DkMciAZvl0bgyBpPUyWQLRuaJx03/Q7 Y+YfNO7vOT5Lc6SsexVk5uexF8Try3FskDXfzahIXaPq/26CnPDT7uVuJeGA UFjN47u3fcaE2JJgIFjFLF7a0mEiRJA4Ww52dF1dD4yMfB8OlE60BFJUpmZr bUzNayVmrTVNlrM2+/9rRsmrKIJEibWy8vqw2fwHh3WmwQ4bLgUbxSLwNDi/ noXEdyIQ8DW4d+wHBCBnrSgzzkEGbAHK9EHw2o29IXLIENghtYbo3BhTXQnh x1FgNDQCl7HzN1TqiIH5gIED+VbG7FIU/tBskblPKZMO3LkFI8hcLjrBRQvr 3ggkGZpWCiITKxYrAFQS6gNz2Me9/qrnbFGwjveg2KotN+VtHW4aAmDin91k cJz3dDOajcsR4cQnAfYdSBp48FHmDqLwz51nzAwbm5kKccXqdMET4jw2eLlO pfxIa8+3yGMSMQsAbYx8uomVDMQ6YzCND1tqlweJBsLs9jD43JRTYQGEGToN 3jtwROW1KYOeCaAhv/D83VqmVubqA9mfhXdbcICMXHQA/dFeUKljnyLETjdm 49GAuXQQAOW05S8LqLchysl4WJiVArJhZFN5BCkgxBxiAUd2wQx0IkpA2mNF heMIP7TIahIan1/Lj6xyWDWg2Ry2pcJPzFsgyE6cZXcVcZYNjdibZS3GYSGQ 0ugUChDk2t54ovq6FdET7iN317yv0ufU+80P0lC8o59E7QR1w4ntfDw70UBO jxMIZ5f7RSoBxO9kOQO9DZcYxmdxiwc4i4DjlwMYOmNcXg7yxcimZRNyKhyI c+qySZqilBKiE4DNLkihXd1oNZoyEYkFN74yXjjWjUYx4QMEUjrWg0b1fvpK 6ZvDDetatO5oW2bYNqoWhAIsAgG25aHy8a6NxKBOz2q8vzOBsWK91AeE7QHh xpkQvLQLy32l3weoGCGUZ1cKqrDS2fBWFrf8CSQJMhihHVhLPIdwDvAEnXgn w97A0tHUDex3Adu4vm4BDqGV5RDSmPXrn1bh0QASdgKXsI5LfsOC6jkTAX8N C5dFFqCoYFBe6KiXitRVSEZEVJEADZA957QhJA3JqF7YajBiKLBYIDCOtGHQ mGgE3iVPmhr0nRlz8tDcTduNjhCggm4DR+lhu/fZt2YNyZlpYCw8Cqo/K6TB ZK2Pi/QgDwiAoVJuAnQE525NOJbPhM8PHicMTm44Zl0M0MTlJ0DkIQ9m4Ck6 jB1QofSO07hDIQT3XJLvgnxwZDPuMe83LkjhhQ8qTu32O3BPi+BSCgfAIqil uVdCMgRQIiEBge62QfiwKHYyBxO+AQeJs9k5ctXJz2+FxbidTIyCfHuwCa9O U8PDgofhsuw98RkYsERVAWAjFIQSRA00hdcH+KbFzPlXkMdZ1zQ7LDcoFFPl sJv2nIsBzJigAbKoyPzSwdAiB24A1frseGmlOtuIpW/KOmCLCIj13MjTDsB6 fCiIroa/P6w96BZ/dAlkDu5V21RZmHOxODCmA0SwoQj+cApQRxOh4bvIOJaD AsCOq7r8h6caQ+lrF1mSHFTYvvtxG7WMRFxDMSP7Tk/xFEq20Ns4iRn9G/9T gps0JsS6TVTXIYbNksNsMImctfTk5dfV8SCoe/XwYEfC/QxdD06TluMRUKgX 0nn0mIWxHETTQuhqcpC8KIfAiId6PeLQXWIyLJCiheBi27j0EkYQiQ54iYCJ RYMRgwvSnexWHEqbbPMpppIBKyIzZgjeUZl8wauWYSiDQUgmc82OLF68dNua bqFy/uCiQGdjjmBseLm/bJgfQ35hzF8clCYkl6HrT1g2xYpeRwCBQJP7BPG0 7Ma6I0nCeUJR02EcZEDI2VESJWURjyKQ1sxgzND17gQ61QlV3zTmGm4h+HMM GhwPtXqBd2kXbj8GPFyN46wK7RXKuvBs8OINesCsynhCz4sTqTQ8KkDt17Mc HnoKelhsEANRh3ngcuhUmXJkJqG5D7dlAwQujdoDYCWjY7X2KZGQ3QXTib66 lNU95qSEdnRsIMDmurmOEGxTSCsu3xAwODWwGmV5JQGt31rVWjWrSmWqmqtJ JBnZGmBJ7iFMLG1sIWIPICI5vaQDjCg5+lBEh8rcBKiG2jwtUXOLcsVGJmAV VDE41t4l3F8aMTgzOuUCxZMt4XSwpawhSFjJHvUC3HXGpwdCpmnu5+naXAMs ATwRTZFATWwlU8kolNuVC5iQsOBp17dZpCvUfOGafluJTFDVwiHFMhzzE3bl OF6uCQKSqDQaQzjcEt4+nEU3gfCb2CuWsBqyEOMIYJe+MSDuCKnF9Am0EG5q pEhD+RyAiDJiU8UwcsctsVbAmY5mZSaA18qrjLDqcvRYFhO2w+CJAQjBVNG4 aHsZfj+P2Z63WnIep+RfiHx9B25F1UOPRHCIRVOE+8wKgJjAXUxD7A2SFhnD REmiF46kJzASCJvw6oIuuFNEyDc6N6DYFuBxLeiUFn9D2FMqdOB4llTqABcO YuwoQGzASRHIMHXxJbWJW0lpvPxLPY9qjvZk2ih6xDG4h2ihYAiNoBGqhKlK Kfjg0CqYi/CBJcsWKXnzSbwkh3nibE+e5hU2UPCO5ClwOYHbWt9MpkIQPDv4 xLDSPv3kG2FkN4QEOfLlzX4hwZthR4ECMkaIRYlfw1W9x3nLWrh3eRxsn9HW gMYHDZE1/07eyCL7gOByty5auRdTIygQMjrFkF5h5sHM9wpYNDzEHuHDI7Hp n2Bhka4VIWwDyjmjfY6ucoCNnUsqQo4E6p06JZE7PXip1Ous0M17uOocIN3T IcmDCdgu8z6rxXqfAPbfUjn1GGzSN6A4RA4bnTWJgRYmaoLZ4BpPcPCBETQm C0NO43D44Dm98PEDc049gd0tFAKsGQDEXYDE7TEpvga4U3ONyjInhCKbHmGD RLGROrkDdaiiiSvGxZCAVo3d3z8LNzoijgya7UhEpN0+BoXDDhQMNqhXJzqC bdwdwUWUwDyVKLOiZz6Tglp4qd4cXkDgIRAkkUhEZEcAAgIIAABAAAAAAAAQ SSBBE2CFpainQUtZQu7c0dBFupFmkU9wqyCqQC2g4+kCajl2S1Mc8MQ0P9zw fAU2n9/fKJpoiKtRU5mzFj0O8shKBMPURZ2MSSrYHZ/dk8opilh3TNxBMszS PMTtMAqSdjjcnHN2c2DpAMyPUcc4qj7evP2PTflFOMTEF95VDvynWss6VS3n YosQZOuuug7xXJFDE2zNrPRgepty5FgscpYb93EA7xYkhrpv07sO6h4HKjSg GKrSOmeEh2rTQydDUFSwEUp4JPL17k247aEOO1BIF6OL7J2lLolG8Clc1sca OMRfdR8rPOHI9KB/Ou1VyAPMLnBVdIHKAZ/Zb07DsYQ1cJ1TXxwfEi2SCQnR TwEzN4SIlEIwbhn24qfFC+0TlmBuIXLkL9MyGYnclBPA4onn755TexEkEYJ7 KHklD7C60nFUm1E4SkdNwSJQA8TIZfJdbow+z6PHXXMT4ElN5ck4MTBKCTCI JNHm1IJxAQ0gLQs2gq53cXA5DCYa6octsMfsv3/ARO7pSU9VSnkL8Q5x6RJi eYMVehy7sooQ27ZcMDKyj2CQPP94zMMfQqEZCRZDxuDayetgyBIbUUNmdSvS rZqiht5tB7HWgQTtGaKNjGfnofREJp7pD6cOriAThDGdEKgbOpTD7Rsu9EJY whsLI953a22GPRN5v8pklvp6DJU7UNaiid4WKNjYk+TnfD0RDIA6iWThxLoZ KBJjkx93fjxyGx3/DUzvC3GZhMg9a24BnMGeGU4CQkhCIQed9RSgNy48Q1Ks inE7dur2EBe8ydE2Q5duzRw7HTR8AEOhs5JumLmkIsF7vLcfknz+7y2D57Jw O3Cw6X3qyh7N3gPXe5aIHsoYiZS7SYCRJxAzWzNGFj8Z0EA9BBIeihQggQC5 2rYC1zw7c2H1rmK+8iAduwcf0+pg2+4SzDTZ375CKczYBdyNOCQKjyBDG1ki +sG0DuDWhjwMRCiFPmG+zgmLjmVsMgwHMEof8jgDsg/d8vJU4VShtHU9B0Cm d62t3OIjhl60euoYsbrqLcC4o3K2gcD7SAFWCNWObibbpBPTKhtTNEk7skCE I1YZZbC9VXPUUxQ7+/ObnoOaOXnucE4HIUlMgqJv/jPs3Mnl38MZ5jycU0Gh NRaRgBiAK6H/Uz5C50toBeZ6XRfIsCvxMI7xHhPXdSzTbnUZhdPQzXfNVX80 TbYcfKX0hO9fcXOfpf19LF8VRMJ3ccA/VFT757v1v98fx24mL8wXgH9FfnQ1 AfksF7GB9f87kofpgp7P+LWQT7QwVgEUhA/ziNBE/bD8f3acZRooS0UAygGU UWvr0BeL+gPzP+wH37lBFfjICfaD/QKTVA/+Eg3PksMeo/EHOYpD595FH8nP AQERsP4WjTQICkZF/Gzj/pP/A+m95RrA2V/u7GQiA4EQr/7ZtID93bkH6/+8 YHy9rVsg/Yv9KAkoyTwd//w1HQeg8wzkqKGs/9c190pz9X8cgT7J6xPUfO/V /qqpUWojKN4Hl9ik+c6fH247Casdm8Wmj+MjCJESfgPadi223s4qTpJJ+sG/ S140h2KtXcx5fzmfXsXLkDiG+++5XZ8KT+cDM/yif2gUGLRKO0P7QjX+jpvc DKx2tG/puapSPuEH4GbmLSug6qBA0BGZN7VTAftSbncU6KbQWRSjombHIAvu YbPd/dZU/1DNQSbf5EkfkKqvKhhbFo1+ROibzZv3KM4ooa0Joa9Z/UXUgzCb ZONfe572TNuhtuQNEVJqQYaCjOGCxrmBDShvDg3qF6F7ltOJPNmng8lPIy/f +UKQMkHJxrpw2jCqKkISjnL2tAgIbOgYvjujIPItiOpeV8YHRS5SUuz5OXDN ucMNJvwax5+QTHmLAZbQhtih/D1HDIguQxwoU4x5QjyKTiJkoTud67/ErQlQ e3z0GMV5RQ3xNFcFs8WFcMzC7vQh1DdWGg7WY5wSLC0wg1z6iDOxq1XVSah3 y1DZAEGFEdQsBzsmvIr3Mvqm1lV6XKH5nCh33MajRP2U23JsSo/dmVti3VRt tiO5Na3cZqyFFszGiqMYvQUTojOjEuQhCBCYVmaLTBtzh0f4uZCOxCEw1e/b kYxJZ3ZQ3lJgQBrTUW565a0xypKSsjvMgMrOljc2Rblnx2Guz0n5tgLs2mnA A2cdtWvTiWEP8MrlgdZEA1nbxYasQ7eHQJGN5SX32TvlIwT5nYEdIAySASXi BUdWoja0W9lu8cBIUoCWBMagcstImxmvHKBNV/Oogwg4o0gwHTyjhJIXo3GZ rG9gnKGUDCIbDqW33TZHuiHMPbtOpthRcsNi9e/M/Tuw7BPX7ZKWUEoYfWka 8cv1vOTxERGucjdd19vzop52ucjXF1wRrnI5c1x7UwzJMOQQ7ux6fZ1/7GAI QhGkTy+X4EiJ6hfrlBmE1SA83s+bXM90PJUVtU1BJj6WkHvrJTGRmzDsgEM7 c0DI/3xt+fPI1VNcFhcfKjT+9l+DzitKiE4MIe7UZiS2pM84oV3lyJy75bJh Ds7js+DubW7b/4vEKA67b407YkhyXcmFLiaISUw5cszHweYlcdw4TE4cuesN GAZdwM6xEMbgsbJmgV6kECsMcjHq+yig0aW0xz4CcT3DzuV39seV89r5tV/M 5vrO4OBoWXochhuj4PEY2qkzKjkG1mNC9jJSuGKQm1bWtibTKwm1xkOkMk3J Rt5QPwNw5xA57Y+fQptmb1Y4hJLce6iKLnYoDWmNxgSNapmlQGWQ23A2yrTQ MsgqibTFzMDE+2sMzs6bXobryAbnlyOw2oYC6CwuoW2uo1FejMUWb9jUDk66 0Wl5hXuRtbPXgY5AdA9Us7uYe3nxbbbW1ttrRqewz2Hu5gdDu6CL0He3HG1n ZsOdfh3wSRw1I9YyOO73CiEljnpmh1XXwCfVH6vqpULbFLkvpJ7SdvfPEohC 4DmpgMtuezcPqINU1rUsG4sOJCIFLSs55jxH3G99UuB7uvc9Ietw0YJ2iY65 phUkPkYXKgj3ycgPUc+ppXjo+8+WKooYHrPE6+Wo3MeR1QI2Z3SdobTW0524 Dgb1b14OTcSKXeZrkG97iMJ04geL2jyNaa8KIUJrEC3lECIUZZZZa2JlmezX SiEEQZ4MnceDQg7JBqtwb+GPVQSHHHQmQkrWsLRG4ZrCxolpCsur+v/DF65C zqE5CoVjVM1paciJv7Kc6SxG1m1sEqlYSzW0dI8Y6IQhiXPVrKPsLitV/eKH 4ji9nTDSEIQQeA0/E40log4jIJ/mJVuJ4vzIhFxyKYL9DTw3QNgQz2tA2kNM 5ZTSQCuJfo/JNjyAQ3lFJ9HHI+TYgqfOQbe5szp7njefLWPXlNcittVbs9Zh 15co4ckU6tRrRRZaUWWySgVDlJPoAPjgf9Znfh3pmMmxDb7ElE3bNEOLSY2/ uCWhfAyIc5TBQ4WJzxLCN9W9opYepPq+rqWnmfqhGK6exTSPMiMtMaof5wSw Eh8E+5sA9gJHmQ90sz+vh+ncvkhnIVdO48MaF8dRfTlVRQhY0n7P9pVag1+J AoXmZ1b/thzDigmAsdEvo3COMsDnGtgYCYOcNLoYI6TEP87RjzoKDDmrar/r EpIQ6wm2kgMsFQ7gtytYMr2VBPDvYkfmE9bO7fKsYKRgsTiaHvvITMC6Eimd F7vluFiILAioTxDF8j5rvOvVXSCodxEB90AKVRWMVBVWNtlakZKr4m18++vl lWm2d3SGvauzXTNa5UnBlgp9LUQSUYwwnUz3Jct0y54IWhNKPfan/IkpXcwf Dyrh5kMlkjiMJRCsOdsaP7+h0jHQ5HECDC/G5WUQz27y0LPcurU4kPWtjV+D WgnECB4cyMYRgOPgX2AgbCIJiMSEIREfH/UoQsJ3GI7gT6n0vEX0dNuaWjsU 0wproMwtXLVuBhruvMuHNigay4orEF2QKAb7HqwMw+NnXzsooIk+DUikP2pp 2zUDoGgHNNBANv7cTXdGFEJm1bcaguA6FYjpljRFQ9lAvlFU6SRciMO41lm8 E1ihaAELlNFthFJu5TmRhIcOKeqTB9bkHtwH36fkTqEQHlQ1UCR5lV5wosRo QCBREsRbJzQ7y1BfTsE2C/RpSgz3NBRhiUHEqbPrukUdWMF9Ah4jO5LGesVh 8qXgrBYQFfGhIVo0Tkh5gW3IToIHwQLJ/Mfq0Nw+Iagak7zHUfbkJgAobkTI FkdGAGsQIiEhHxGlGNFQUkWGmwnr7vDbh6meHc3sRjh+4IQnFKYHkdHgf0G+ 6eZ6yP2iPmaJR98ZFEGIUSBTmaPYTl4lE/QYzQJthg6cotwFxuDoOqEGH4Gg DJghsSJ9RUSi6ZKgRHSAcWFiBTv9MHmOWTRgNORoq6A1KGICw9sDqdjqYWWV Bzz6JMa7sheKuGhIcUoloYIEEkFFeOaC5y0BsWz0OYHFEMhJATERyNhyQeqU /fR1SBpuZoDRrma6+fieVWQpnJzYL13DioGubw18TiW/3XCjy/Nt2Qyhj9UE 0ISMDwhQVRQRBOvNNvc2idk+11xyDI5px+NU7IQtq1FL1iQCk9PLuMpvG5D5 6CCF6DwAIJ2ZPtU0kMJmpRtj9XmcmlQnBD+eueF53eMxVFiikGB6TqDeZs6l 4mgfKd6bM4nYzXkyolMG8Mm2wOgQV6mYiFV0CW3rxSIuNSrzntnpzKeJYH6f rT8jDqbPWQFu6FwDuDclDtAsEDdK8U1OZr56Jl7hPo51X1CKvh0nt0HUQQQv FEfPMD+hiW9EkShDTsgiDhCCESLIAqvFT1ICc0OUAgwYRC5ETrY7Ozykrjar Q6FK2GGDoGSF/zT2mBDqUGWJDbuKQ8+7fr1aDFqWVrXG5aqY1uQfdPvb78ia jt2FjeRTuiyFVSRgHMmcMwnEeuFIi97UqzQBMnJngXWdzGHsdmPhl5dfAgQc zz/33YVBpDYh+NqsT5CYeSzYpYmaKOMriX/Sbkp94JAgpHhw+ZEYHAHl6rfQ xtVRYCxwDhUYG4mumyoxsUnwCrlpJpA5xHbPNB83f9zpb5MPDKlZA8IlQwKt Z1fDZZjGwZYaGYKVP2ZAouXMOYax+FtyeBnNpHhDe/OxjEprSkErjWRPGzsI 5TRw4Z2QvKnuLJZD7jv4GYCta5ERBYjG5PAfgeoO9ZH6Ynv9qXi92Q94ZZLZ /LdsJkEYS/A+tamqiJRuoTVHo++s55zFcvMsJXuidp3hnlIxmudXttraeeXW nh8X373Zw9cuIQHmfnJARuXtzRoQGsnEBsIlq+kWCRq4OBYgHbbOIPvMN0br 39+OMvsKO/qRg2eacxY9QnJp7qy5Lt7uyred8Y8Z9Ozi7zOwFRexufzypy8Z 3IQhbWem9tA0Q8T+HFNCw4NRu4wR5X40HQs9QgyzbGARQ8ri0HiI+Vge8voY dhQi/rlyjIcX7JghjcUnI0C2HeOlTZ7P80u54eCSjUcBw6myjsExLHQDc6Dt PEmO5UVNgyQjy2Hl74np/pBjc1erQuWoBMRUUReYI+V2bBFl1SolTJnX83uq /fPXsv6hOZR6VBvxBueRlkAkGfChnb+4ljAdSgGEwH2lWsCVFmxfe9gAPow6 ABoPAOAnKPkhPzpD3xJMPwUxmrrLi3254Z053lnocoC3XYNsxLBeSJjNoIXW tRodyiMzQOkNEQ+OI+IC4iJubHTeIrcW5sVokm+48vZuUsoDHdBQEQqCmIos Fnu8vMt6uquWIolN12emsWoieaCJD9WXpjutI+MHpO6VKj3z1b2E6GMHiBB+ Z0+CFjD30LEUHtFFDv6QADZUDUhonj2zKfAMxLKYPtdc9rneEHSbLJ+DATl3 YShJ5+sDZNPwp+dzVPKK4d5LOTpieOwKmFiiHVDvhMAs5iHMRzmYTcEUKlQo iFCh+HyihPwBYPt6kN6Pf2GZjNUK6VtC9N7CE30JIl7H1ir8fOJv6EYRAzYZ Iy7DJM8sxcEorqDYOJD9mfDn27ZmevOp2EBZDtJDqoLETdMAPQ/Rm12XxewI ++3PdMLmBmaLa1iE/UzqD738UO490whtE+E9Vg1aqzv16GSZpoCRxCW6B+H1 EDUNj7ToW5/R4WhXuX54XYJicBxqNQ+C52bsE0yHWxWgctUVcAwarSRrqG9l bQvDMJtSVM1QVT2SOhwNwRgcjQfSTgeDSBRsiJLBTGM1oUg2UQ6z1fmvmPlv iDEfMoeM8X10rGcDMQMFhECCwO+JIYtDAeT/I6UMUccCQhCKOhY2+1Oatj4X yFqi5x+ghVVW3MuSSrvpgqbp6mFBXHvtxeKaZh77OX2mhxQTFlTI8sLstRn3 2hs2RPuwJrkya6Hp0Ncdwe9gWZSzRlk6tL3ZYjBYRcL4RLD/HcTK9prsPTEI t2GeHC8IiWGCYfmYRpEFI2G8DDQnIc7wax5NAbysC4eYZw0DS7qRDyPKJp3J JERLy6mamYtze+lmicJeGk8NXLh/BMNE0eENoQ/QmWZk0xvfrVXinDUW1tJY e93obFgcFdiO0rL4gaHenUOkZ7mv+JoxxIj4+9P3x9kVLG5+DhMS8aqhzhUz gtVi49mg5xtaqING5r6G25ettN3r0251lsWY1rjgwc3MQn075jaMH5GCx4kU 4iSLe33JjQ/jxk2ObwaQ0qn8CwfbnUc7OdLm8YxdGJqKknF4suy7u7wMJA1u AmCgVWQC2aOsQG98AeCHZyHZmnY7bWE58zaa1mN1Il1hWPkGFDRDRhOQwLhB uBBIENNeMJGaj5psaPMIm2IRAVSIwUUAT1GSKT1d4+RT2T6DzD1opa1O7sTJ k4tw8Qt3inKMT5B89xo3zJzO7cA5CAeX0HAqAQiwowxCpWFMCMaFgQqSRAsk FAILUke2eZS6MOXIp0Ws5YI6wkBJCDwiZAef7iyAsUiUnaQk4rQEJ7v8KQX7 esr75oBPOQ7ETYggbixBXArw3d9yHgVR4EmFOF7YYLJH5eRIQklJUq0028xa vwCG7s6bVsHnkv5ODeMuiQJ5CT18l9DNxan4/f8vPzREEQM2CBocCso7uHNB eG5yBTtN5ozeqw1JoAgPWM6gwsAyo2jDWGBo6AE34gecnXocyyUifikyqL+t BE8DP0C53Cu5z51C32GZyqlpXVUtpbS2yUzU+YiCIwPBeQKF0TWRA2wOAXHr WhLlSMpowMLgOZcwzL6naRRmJCLQ8H2cfsbECeXl1AzFjvg4EMcF7BY0yHmp z9y4wJgcCprs8yH0/vaOLDZIEE0ok2IKQse0pPHe9bNvGF7YpDjPEzrBwqRK 5ze2HbPIekHprJOkmAE3sg6C+Py7BAdLycZXyA0IYYEOJf8iLx9Y7dblgjvE hAHUhYBjKfO3V3dTKSily6tFFFJSUlFFJSUlVFUlMpK5VykpK7q7RSUlJRXX dTnUVFFFSUlJSUykoqMan8C88qUrpUkXKuylKyVkruOL7Mxcj8+O94QOKjZq EVY7aFm7pkTw6QiSjpKcSY9I6aCm/W1Z76p8RGyYWDNbPxjvEZgJjBNvH7CU WumDMPgMMwHegGSAMVxIe+547tKE+2OVHywn3PXDdvL8SXttNtG3tgaSCgA8 myBI4iyValvikcRDGmN4ZdbuLohLmkVUKdYVNaLokhIIY1P0zTJYweFZC4AJ QlNTE4XVd+JkrBebwsNaJeXjEgBe86P3kG9E4ItpczRQVEiRDOoo30xemoi4 sbkUcanSb2JNN9i9UgsJmFTrVVQJSLJGWCXuFXrhpc01oMR0Dllc6LLDObNw e/c6qM9xBU5hHMLR4rllwWECYYIffsEG8hu25B/unSBZOY5Xho2FplyZHYtQ cjnZkNKKYYNbM6HiTd9kZ7UK/2thg5JQ2N9pbqcrV8ZJyMSQuHyKNtuYM2zt yNa3TMM3ejg621Ji8NoxJPgVq8BbbafXPXo8cNKW9REXpDHO3aZGDRwmYBh8 AzkICEb9QW8jDM90XvhOWsPSMHswNIzBBKQs8oy3iZ6YgxmlPQ4435zhMJQv EBEinlrhm4d90SK8Dpsb47OGb2Q2pFA74Ww+xvwVg3fYhzJA96CjLk65H7ms 4tEsmsUbj9Ya2uSOjEBwRDP7AwX4V37nI155bVe5inl+w1eZGi1IJBLFtlGK 2qYmpB00MnMOYJdJmIajafJpDE7WkyTeeaqvWeOOp539uc0ctBMccxpmih2J xDZPNJOojDQJDzTfd2vXNBslr5HHHG/Dns8dEgY8MB2iNkliQ6icDznrI96i ax064PDH8LnU7butnSc6PXS4WxovBM4xqdAskdcXtgM6rHGdRgfDvqF1zTbV M/Sc0czmczzTPAw78gawahzBEazasLOSCLyUW0oLsz2juq4LGEM/SZQ7LBR3 iGhGx0BzB1Ig6E2TsQUNZ3FGDF7Gsk6o8DWxglBRnA5T96wu7GQHJ2TjjlOl AoIuDhlAwGSOBLAIUPK5hNeok6QoJAMMMOsXszzD4YW93NFRUmujBnkwi9ii am17dfKVmJhOKWdjV42F3A15yQqyEU1aRpdEKU0u2LPQ6UNaBkmtw4ZyEISy HbK8A1cmhB9x/bzADv/16AyiwQISEhAihtgdI7UQswKMr2+8B2CYG92H2AzD M5AteISPLvME2w5FP+pghkHcc8IN7EhflwD/EyYP5NGMZNhHRghWkSICUQ3g L2CvmF4/9b7/No98nwDvwDvPQf0hSQGNopRBDxovdClQuepD2+knrbW9D+G8 bwQV6r8kSPAvrieE20fbuWmg71eB3WiANsGKIE/540ISb6AsjLOPxSf1GG3e doTxaGooEEIQkkME7pCFdmW0bMY959ozG8Zr0/jUYpecEsLSUG4nv7he8z+j cmMluCK1dFUGkUCkSD4B0THuh7B3aDvkNTvKCt1bHh3oyK7/Qh9eIUmh57Af 9BcKDbr4ByG+1ZeNem5bepjfR47fNNXgoiQc2odGyFjV7fKgsQxyN+T5ReO5 Rn7DyD6egfnTbHY/8mqignu8J7vXfU93vpJK4QSmKQLVISJ4QtZfxaG51TI0 jojwL/qJjxyDjlDKfQyCkrF2GYGerUv7pfmGjIhEejBOsflDYGvjoBII5FLQ tmi4jk+eJ3ER4KXUfQcXmIrhFfE1hIkyCjBZELoLI40kr6hKnwhGBANQmvbS 6kip8EDEPgMCWLGGB+zAxi4KTD+sOhjb+/uIRYsEPd3FPgQTC+i/Kp8thIy3 wEx5Dj+i92ZixMDsKUPuFyRAQhh+xSwPFcDy6cDXSvspAwQ/kQM50RfzJ4m/ TfCfxYnRSlpH5RRdoKW7FKv6UQggPRgDuc9lNnvTgftIkYRCRAIixgIMQ8jt OCnn9ds8rSFlc7sIaDk7LNEk3TzLCv8CauybHh+UQYMdEGcmQ9DDEpkJBm31 LxtDHEDM2YPNmtsr5yN3WtsyJlkdSZxpPeniJspsp+VPTOZ6M1IonmY2CwOe m49mWsRLgjq4ZNn7LvHGEJhugf0sgTuNz+96Koiq8unGQhzhHMNdjk63nZED 9Vkyhy+v+f3BsmzzJCRJEGTJDwhYyKQRX/KEgCQioYm4oOEklFAfBk9c0+n0 2A2yovIZX35DsYT3CAbE5wgMsIHxoVNsMc52sIl4JYQMrJqR/ANitriHVJZl w4ke1aITWgaEDQjYFqtrFJevfWEQ83ECwUcqhSIJV5uJfV6HifUTHNhWQSAy Q7MKmDI1G7OJkHTinSgQtKlh7WGQwiJ4dITQSYCCyGbH95zggHj0QYeqD9n9 2jPNm8+s1TQaBpTjDE+pgU2CLBPNqiMqfS4MSaKjbFRtVr1St+B8ufHq7e+5 Zw4FlyDH3GBT74ZBoATQJ1cWrUG6bCX1XUTgjGiwHotkr1Qc3ZEIZkik5nxc 2dAA4QVhEJtuBUP1Aw9xhYEgwikFDEFE9sC8fo85Fo2xMPdHEf6SrMMzC2wN STONWLlSUSFSkSVpWy1tpStLRsoqiiKnzEDG/vJ/L/xGbHeuwRYMo1h7BKhQ XQpxE6Pr7RT7OD5wPsSeXzUKMmAoIxBSWMhAWAdSupG0ZCgjVqD47KUnWFKA 95jG31myCJ0E02C4bEGSxl3LwkQIQuS0/lE3IT/hZrO15jy1bAvLCSdHUOOj xoGcU2HWgaYDGJcwdaEilpP0HtIbQEFJTYOhA9cqAbpxYabwu6hVVasrShjn PEXcyjnkneBFZ8Jkw4xwyGHb8TQg+2GHZqO48CJPYJ6yPj87VT51Faqq98le h/L+O+38F8JDAZ6m0N/9SPHZ1EDR9w451ca2ILP1Jyexh1+36U//JLuM0WIc ItyB9D3iPeGW8xWSZlpWgK+Yr5Q8Me7CCJPHqUAGIrBLcTTpCEGET90CuO+4 tG4ijwUATSPfRSAQtCwZFfO0QZABBgBBkEZuIEKgkBZJJ2LAD7WYBw3hOI+T Rn9r/VIkOJxvJw1GP82BiYH3DjjD1o8nRkDGQUzDIlMgGK1EBJEkidcIJ9DQ iffcMRajUKKr85qiga+ps5szUh64LAQxh74SmJkE/iD7CqUnbfzK20w9ugi3 7QXWkJgsTW+6zzDeVCIi8AhiHeTNAB6eyWOnGPR7lNaOJxQ9rSmksjOFwwxy H2KTx/Lnw+X7+xscKrNzd2sl+mdY2qu7B6m3M3uIWufQfetY1zuc71io5vPM Fzjbbas2b5jryt+vD4FXlcc76xz14OW6dc61telida2Vcbb9OVKeX1PPNTtf PHG2H34MLXPPPOq5zzzxzh+eTC1y5Aj0gJIKhoJqu3t3wkJCTiYF6Q6QCYcq yIy2OOzZe1pih9W5KBAQhCEIEJ+KWiIIgmtWYPkNtVVQqDaCdIWBt86O09vb KNOkmLHbDB5sa+pv7UZPLJhw2JMEKxIDBSTVmQwgWd1qJ1125vZPOvS3TUbF WyKZtpIxZApYWIkESimpwXJlNGkvZpvbANEUq0kklMrayDXbp8OX2aIaufKx xTiWB8Cf9uL9g93kB1iAfJgpH6SlVFkQJE+ldCxcLvLy8zpIkIQIWMAsHJRi MRGBoTqvpMqPFeDn4d1wQwnMVkkVnMjTIW7OIYFrKtoPRGxcCIghnD1CTuNh pk0SMCYc2uclkAH6tvnoCiIIiiKRiqDOAhwH1Tunq0b6ZC+siHY8PIM7KnOB 3HFJUEiJKiUJIENegWC5Ud1HhnuJvA7aAHFV+qmu8pDySIgKH1MDwfYhpjLQ tNE05NMuCBpNGMhqOpIGkowmMzKiVqko0IUWiUCyrWwL6qZImqV25DMwCeA6 42Ye7UL2t4raPCFLQz6h5AaCbDdCEpy7U2IrFignQeImKjITjWqRkEIIk0QK SgnoAcsE82UBwLBb1zw3FN/0kCQfRsC9kQCbAjifs6W6rCJxI0ah2oB8zYe/ 5QO7a97meGhg3fNLVO07TjYgn+yLIMUCQEigSJXuWtdptVk2TSRYyhE0h8XD 5kr+/BgQZwE1KFNSAdWKGoEMy4DTL4a8DLDkc7Az4/2EO/FHvwNzX4UwDaY7 VE78DGb+paWxjimweutROwjAkBgiwiyMjBhvny5n69Uc7wswTPq9UU1jpgiO wmObe5LGnP3lt6XSGkTIce/b8mJjUVBdVawXsSO5gzGAeL1HSR6BXCNLQcak F4endz+iVC9ulludtz7dkwblHEsegAkNL5+8eRDd2fG5Zm5XQdJ2GDsde6Qp VzCgxMQl8lKUYuVCiPwPzV1MPohDp4RJ4ywZRT1BwdCyG81ynRWiLWtygUMs Le3eT3vi2+v2l2w3gkRaORS2RG1aPEpLem9jm+ott8mpXzT6jY1favm7w0KN FGMA48LIF+9PIsglShpQnEDKWD7YQqAHKGYklymgZ28dEiLmCUQmkiBrMrVE pnkVD71MmRuMFDN1NjkDCJv/0lOg/ion8Ro00A+XB6HYPcrk7Hfw06ob8PPn AfJk5ENnhdgnLvfZ1n0HvalulNiqLs8OcFqBde2nR110z6rpbdB8zfywa4Nq S0nmd6czXtWxEQsQRIU2sKHtDB6go++BxGFk+oYf50LBEP32TvIwMtWsFLaS rAYCl4/Cf6gzRYbSyhToZmt2E4IhPV8wJU0P2RGILmWGP9GqAnJirQViqoxK 0FPuC3ZzgQh4kmjmbhm2lqiUMk7jj3FKgd4QBX2CvNV91BaHcLo6a75KOA/1 6PVk+JsRg7D0CiD7hSBqFFXNIDcgSAisgoBEYqMGIBCIQxGlHhVKP9xAEP7L O33m5UIT5duSl+SbCDxDXsbahw1RNiP3nMcSfUj1Z909p8vvul3g8GEWwhEW AAmM14cMXHtLMUIFwCEUwWHGh8DAnmcX0+1+B4B0QIAsF+dgwut0+rc3hxIR swsVDLTvghZtHlW/pzkk3lmzbbmb0FELvNqmgWICrWBpDIiBrM4wfyQQ0gyE bxg4oDQh39R1d5d2EzyMCtSoFjCLMhloL/R2O4AiRifaUtLBLBskKp0DMyoJ xEBoIQWuG9Mbusrr5m1pWk4kBB9HiXgmPqkp85z+Vzr7Y+5lDb73vuDkFE7g MbauP4GTa9MzR5nI4FjWJl0R4d5OLMB0W7p9sDnEFqO48pRIjsBA6BIZO8Ec NzAzdrBiP3gxRYsUxf84HSyK7Qd5ulko+ca0T3BY8hXRqMwZ990q1wCghsbU 8z5TEHhREBI5mXpPQ4pGVVYx3H5ZKSIJEzWNAkHipYsZ80OBwBYpIEJBISSQ gSJFhFFQYxAQydU1jmDvVeT6kwRcTQZ85q6WRQUiyPJKhTMSK+aV32b1eK+t fJZsVKtJaiSiWsmsqWMmltJa2gARZtYLweAu8AKBD9zDkGxF04RexNoBciH4 xQuX8abPJWB5JLExHZAgchNRx7+JQavBLyDAVGgPphYk7igf3HeCHugKWiLi Ig/ZYySEOMJqFEgEm43ozC9MRKOhqh+J5H0QsYG7NpkkCKHP56U7vQ/LC2ia JAiYD3cQLaYbjMo+pmAHadzqHLvvX7OjgjEIqqwjCCoKEioiAgsPOlkTKZ4+ lKOGd7v/bneGKhokTVU6AmIJP5VR3Y0JU3pAaBQI2gT77dgVME7wrcqDmlYV 9AcEzANE4j7L7TwLi2YJr2ctdtIYuss+WVNsKQHBSGIfHZOAnKcuBKJ3DCsm xkqiKoQp8NrdF3gbbFdw95AOJQZdCAnZQiIfIE59ugBqHBaOlVXEHLuUVje0 ikGzt3FB/HACgGBfeK8mDBLQkBpXeNBuFnYASuYcRVAc+XI8kzhAD6+bhD+q HxyFGiIKyqSv/cgZO4PHn1txJVzr5uS/U0oaC8znGByiHd7cTDLzP+/QM0M3 hUYfKq0U5ULqx310OtZAqmROrAwEEBy06uZcRZmZkzG9GRf+yc4agIBiActs p0A5CmUlIG1ASJo/2YH6yBCHjyDGuEkN/QlXhpKANajrFUOZBEkJETcTEgqC NLv1JdYR+zEZPTCNqleb/KyuLVj1Ic915AO3ceye4Ox2Igd4QM9/A5DSd+/n g4Dl3Kd4HSsy9j9lZk3GKaysDPYHgbO7ohk0HKgTcbZhmoMkZwSSOyOG+ub8 O756XO+6dCI5l06Zx+ELqC6QIe4ZgIZ1gQhhdzVPYRkpE7tyxHLZVSl3cY+q m4ORCbLezTKatJpNCGC0d/03kgaXTMs544Q1kNSlIUJ7iEEiFEylK/sTm9OR L2Wh3mKuIwKTkckgqoZ5VkMQhjhZHJNysVZhDwOO+SjCYJSQkyQgzsSGu4Ud jOsGRcxaHUNaDuAuGoLFN0jR03QeOo+6erXuMTtVhwtM4TOmiuZZUgc7vDth eY1zeEEaTeaErGMRWPE6mQN5487MdqqOBoNDaP8YMiEIFJB91rV1/C80k086 0SVbWm+XqQSggpGBwPR+XdHFYRATIwAU8mqJOyHr8aa0ZkP1JXQhwyASUGBY OWy4FMpMLlQwiBC/fKRhGSSGhem8BSCyA6LqIS5VOUTSqiKyLTGlkgnMQPoQ yD/vHHFkiw3VqHGvV6Th9XLWij8YFJjFgh+wKHrZ9mH6uXPbre96MseSjoTi ezXI6ErvGQajCloKRoqAKZrMzYndcrYltWuVctr+QCQCwgYoUSPjl5/islxp 9GijE9cOZHG5IHGIQ2zZLJ5k8xT6sQWTN8+H+FtkJMv5+HxjHQU6kagTOh0C x0Fpf2xfrppDfDrNSKoAmhYPMQkGygdiBqxiSIQkKoEESkFCwQEqym+K/Zpo ZEBuoXedB8SPwAtLjCKFHhEfpxQtuDAfCEiSSbyBdB7kZw4vaFJ0Yl92uUmn MxcQmZQonOqX8lMMrP8JEcptMQ0alPkIF2WSCIc4zb+1VMsAOJF4oBO3+ow9 MdqRDX8/b7QP7DqOL7U+17RMwNymCYwn9K+pVzN3eFuZ1yhvIGyeRAqCGTli GkIFzpzDM/pxRD9iN0LLYDWD9ZA9D9eg36h7Eb25BLE2OxNsqE8IFCzYgwhB JhAMQPWhQka6Hv1YsJBBiAsDagrUBFPdMh5EDvfkr1IdOjwO4h3Q1DuaOPd/ VsAxmyv4wwm0luMyDQkO0t9tpezMXz8HYW3W590lffc0iqXwWLOi6UPmXRHx LIljQxnJmBwPdz2Y5xmWl4wkmBwc5OdH9M9uEgrIKQGJHxDkgGyfdoEmu3Y8 a25A1hKHBw9JgOPXM+N27vG8e0d9LfBmM0Xv6083F8f08KTk5c5xrK8Jkg0b SdZx0Z2moieQoxO1qdTEVT0pSmaqqQqqqqk7OiriWpqh23AsPXx8zpryZiz8 tf9nm3ToBkxbdYSlh59wEwdhWRZCQKCEQ48TDjMbdTxIGp7ioBDGZ/dR6QYQ ZY3Ih7goUahHR4VDSU+su2NpMbYC+QKh8qCXaJRFm2w4XEXGR0q2svenHs/K ZPTO3rNZSQodgHtSXs3w1mSKbNrhP3HwvCUYd/70fZba22njmveBiaw6nzXQ UUv3jNvgajZ6N6akZUNvcf5YcNxDnody+3mTmWbF26TVAxmnoHelLuR4iHoU MTyAW6OulneAgYwUVZIHvsU2sohznLhVkgKWiQihxgGh+8+JraR4lI9dAXj1 w3hO9uFX4h7W4DQChbisQ3R44GsYToGcivGT68Pf2eYGHUYVBJyoa7sugNzF BLeMfEhqvhFUFWKovmc/xyek2ctyhXt3Yd6d4e4veId+rFrROhlolyBej+g9 fiT1lO96WPn1gpbLCpPDIGdqh1EUD74/nPd+VnI10BPn+A/ZAD6gISerc7oW A0sYqiiNaUIQUpIKbgrvFOncQga9hCJGMgQmE8/pguYhJ84lMAsOifVEsK8W BhAvquLhYKiT48vTDUcN71NSaMqdpsNTZNosWChPeQog++CbQYd/z4aip38U 6QrjLVC0LHrSosWWh6GWS5AuRpHYoMBS3U199AhjPm6yS80Ct7W0QOmABxce pH9lnQ1FuekJDvKm3sZk+JKj2LAhU6YWT43o82WL7aqqUPiMOQ9PQ5HjkWmy unvK9JprADz9gIXi7q5gVG0sCWq0lWslRpPij4T1RonkHycA337l9ECCHlA6 aEDvgGzxT5xBiPyFLR55mCtlm5/eIlmLHCZJkoBSOw56sxD8N7y3JuMhgZwi FEOAosMbBEZmMiw0GZjrJuLDRoymHzQgbMA1Cb5WopiZl4YQVSwhNEzJJ+Z1 kvK4ZWFJyNywJM4CLu4PWSYP5owwwTe7YFev2lJXGQQVk7DCG69/Jd5gpqhi 7poyptumAYNzNFuqNbY77XN/ZeHjjjWqVilockowyd5YU1rGOAhjzHHNbwC7 zmSHd8VEVBNTSp5oqpVPVEgOFAIcEENUoTQwpQ0GBghQtBwZ5boG3qkMJeKQ IQybjE0sW5FqeO+QkLLSxEDW6PvE4qYHJBUt1TUA0+lyMEbDrJa0fTc1Uiry tyLAXYfafEKDmTLgsSsPjWWXJKY0FHwPw5r9u+HtduTqfWdg2A6onsmP8Iec sEMz0qcAdorDA7Pb4QCk8xgm5VBUhCwUorYAFwQUA89f/XQDn0+1O8OKagnP g6wB7QtoWIkZkEazXO1d2s2buubmWc8auoyiDFWEWNjQs9yaNXBUkNAwDIwi IIiEYFJPvhYFgQB2aBAJkCSccBmpDcIP6U4NXVN2JSBFBRCMgSCEWI8nuogE GQyQ8t6YQAC87gNGtmGDTMBHT5buO4606lHUTkx60zXF4uihiGauFuJiVMwp iZhQmQBCoHmRP8kBXBsbewabahDYw6hLElBWYlWaU324glk+BDeJVUamADKF DQijECx4hpRsEFs2osEX6wwC6RZESQNooNEE5EpYA9kbwpGMCeUrKYfeDD09 QCmuE4h7kJCVLSoosAfCvseVrKat5Zsm13wtfXG4CXI0nDbuCNQftaU+2bGl cmYbi19QGDViFIGeI9U/S2DQjtie4yKAtEO0gj1N2o7z4V3RH4kkQiknWASL SPabCxpIovvOQDdA6rtUYvMssV5liAJT6ZTaREkgobLZEpoDzDYcbNg8ZAwM yTR01kIGoAChqIyZSibsyXnNIRhNpqarq7TO2mW1GYYuvfvK7QBzAdGjQyGM gYfVqEvFC40hXg6F7IFEOqBguBrFdQwSU/xh7l4UN0LW6lG6/vuOEQQDSbgV WcfrgYawEjDiAgYxRBkAFkF9pAXu4b4LqA4iqskSCg7SRH9B9woUqFoio3Qb wKZ1oojaKWWBKIySGCkJgGRMwjABFsJ5t8k/XxDSonlBG4hrcC90NrUKawCi IxhtFf0wBLELZpGxFYaUaGKBbxUZHu7VEm1t6VzW3l11oSi3MSHMMoExkIbQ gTGE/rZRAjBFCQ2hJ/6QSB1GGhIVIXlSjBBGbYtr7iVc+k6SVaS3qWvabZsh EJAiJAGQUbhSFAX2pUsLAGzALSxxpQ4QR++IPQ+Wc24hei9QZ9uAc8SXH8G0 2pITCtzwd/tRJMxKpMHv3s5GdM56SnNMtjlrK20uUxy0uFY5zuHK9BFknBbx RSE3DjawJRMaGQdaHQNg6gYFxsjAq4HgGlD4uR6fuF11p01Xvb8bubpXNjob XddksilixsUQOXByt36HV147bDju7o5O66R1Qltw7Yq5Xd2OO6m5OsbRuy7V 3Yd2ZWK1LC2gsEtPszCQxkA/Gk+//CDvCTiQqWAcMzGgxWQcqrUgtVhFilEK wbYSspWFpwwtjK5ZduYXLpM0wiljuCkDGFJIB9P4jlA0XwIl4C4FBLRAFzFJ FQkRTWcCcWZwgEV74AUDAgEEkJFwT9sBJrRDRkgNgVXGRBUgDAIVgda6AmKn 1IYCMMgPqAIf2+dCowkNgEqCs0lkSHwpENyAC+2wdgENyP3JweUPLxBFijEV WR8pCifuYT36Ez1/E/rBP9z3HzUhr9FMHFaS2/gEtVsUcFQ9ev0LD7W8u9eZ 0OB9oHQ6HSQiMF6amip0nnEKXGUQuKetF9EgwBPTKvPgmEEOcFWSQQegEJzE 4wJO2uFg2WKIf2hUKVBJFm0qSAlbA+PkU6QYW93dbpc5SUS7rQBe5q7RE3Ro DVcmKIUUlezXgJuOylEDOCKQMl4hAzqGFbf7ihDdVOJBeMUCxEsbWRTQYpUQ 83TsH+HmQDHJ+HXwQOmoHIJ3REUiIITUaMCFPmfGkT6UwBl90LhYX12ycfhu QhqoUtl7k7XnYGiAkIKSP98eEECx50K7YwmjafxoKTCgD8LQekDXETU0WgkI 9a12QWkErv1D8wZNQtFwaI5UDJNhd3yAgBEBkCBmA5/QUNWXCQlyMUJAeoQH qW3nayUncXDZTAbSaNDH0X7NHvtTQCURXaimzQARO8sr+tVT9qEIdNxz8khz zCSBWPoIkBeSNkE3IdF/ef7YyI0mmntH4qoiV2ubAWQCISAwIZ0K25CaA3ak QwQPkXMHyihoDoeCwZIEANcDSuYXA1gpYfI6C5GUW5mFIhiE5vWALZ80CycP zNCZChidtjEceNJrg8RPce7jlgjydOTxPlPhckDp5gIZw7k0ZHJPIKLmNDBd C0Fs2e2C7FusC8XJCv6IFjE2YFxBSJROT8e4dddFKUXOLphA6VURIp/rwzIk Chvv93y7sMEOkDgnJCQkIZ0zeJjymbE3w29KyyMm/XT8n78YK1h7V5ze7bmw 7Mb902bSSPJQOWODoOu5iA6iboKqgjZxjjiH6RFwlEzMzMzOzPMwn8P8oyGB +gI39AxIZfh5nocwPLDZZ1faniONQkKrq8Y3uKUhAoIXO/wMO6vuoE0Nd7Oz oYLFBrHUnDU1sI+E1XuKvg2tqXTgx514gR600l5P/6AweMjRwHM2rB2CtIbB bobhbIpQfrJE4+VOFbx7CwK/552R2o2CPRJYU0Hei5mRwjuwiFPQgUbFCXTO waCU3Pc5hwKqs7X2NqoDpDY3aebooG3DcjZ+1Ph46WxDNVEkktd3NX9kw/yq 6S+8RrzDj1QwCUs2f8oOVk+U4Q/W7VNsJbkFobcrfEAThodJJvQMvLDEuPqm itnN1+3vybtr80+cSeUhvuH7PkVlSFh2thlaXXbdDbRb5rbX6s2Nvbe+lTXD ugFKQZFECy2wvYYQsaPHYEsUrdMH4oQhsEto8XoQkhCSZp5/S+z2oaMM63vz DWkgyLGO03o9Sk7at5SQ73cCGJsNB8ivtNfuNHaZDWUJzoLBIa0K0PU027Ud kfEPo7TrR4C9e9KEsEO+69ZeWw1SUawueYwGnO5mm82UCVUaEGoqsIoWWdsP znlohxrbwm+fsIfQSzsqKKKLFCSUw50BVD8MLxEWATA4xLW1etxznqJ0bdAe jwE9NpOYCIkXaJCAHL8QaCxGQCDzuiGsUtoL+nmexE7yh87aG5lKObJ/ubyJ KoFSh/SP7iXpTTwHmf9IckHBk+IvgELjl3CUeEbEWxiuxG2/AWkqbVsHPmWf U33za0SjjxPYdw/1YNdSekrYo97ZbhrhA/ARsQLuuj2tghCSQRbgaZstnwcI 9KRCBUiwinlDu5aBTHSQPiIHLMzTaJzdm8WoGGNvVeJGRwizmBvvsGqHwEYL BkpvyRAEUDPJQobuKEdFpIORJ5ia/pZISSgaJuKh5d+OAGjMciGTA8DRNgCK ZQKagbgEqmpADULsmmbbBuDBGbLpxYssK/ecg4NK1oM4KMSu0sAY6puEDeaz VxLERRFhJKhYjAnC1NgnsotAM6KApYk0KtLEZhEZSSMk0IMYcJp9famxHWTK mbeLTJU1E0ONWOyr3aczjW5g8ewvmJoeaFkJopzExDgzro0YweVlGIhMGTfS F0guXS5dLW+Ck2jzzb9LV7zfBdhAixMf2pcnNBElzYSREgXSxBBwQEkEAhDI RLA4EtAEwBIDdJ2PaB2lPkSSQC6v9WevIA7uEOG+tzRv86o0Ehp6w4hs1sBw gbmz9x0sO8CRzBOxU0UXunMGU4eB0sQxKLuyBJIshSKGuYUp2RfE2x7z4+U1 uGqG5GQCMAjEWCAgHSBCyv100JhyH496lSQHRDvENZa4OtQkGRAg2gtGlycY EPNelqcY0kUBYHJBAhCFLBDAMgnlHgrE/um2b4XNIrScdaGuBWvZ55DlwH1g BuKbh6w9Q+4K4oRNeGvS4KVyQ4zchHcphtQ/VRysFAQC5EAkU129ftC2gvLD 3GydRZ72dxucqQMIpAFBPviBXYz/AAT0wSHKqDRE0HupHuQuBha7y8GuP6W3 uvk+6swrWkKSBpwBD13KPVKF/pIBoqHIBDh/p+YHIiPsZ2CPCFeYCgG5nkO5 B7mwXaG8FaQg/cTSeZsMPaP+cglp98RsQYRxpsfGqCTijxdqN8h0S0gjBeWg oF2QIyQcibJjQCkvjKkAnIRDwiBqJyi4nQ2+IsixuRMa5VRJykkk1HPSFZDi h5yDYDQj68x2lhXDxD0ldOBXYsFcQ/C6BzFtgOUQy0Hl0TMikPajB6oarg7b dUcqSwsQxwgzMKYW0qKDgmIYpIrILJD5kFRatCVAYqDgsmeIUmRHQgho3VTN KWzbTa0rXKq5bUtbZIVtKNtETvLMyqqqWQixqtHyMoYIhDrbA4BO7pCdCdYg KilJu0dgtxENia6h94bOA0mBJxqTvteZbUuhEvT/Xn8cIBjsQRIBWEE8u7Xy v9yLpfyd4geQoFNhbuuEJyyDHD34+Psq2ZtzSE5k9Uafd/L3Htgx6rSDPW5j rzw2ck97uuN5YISTaQJdTIenVnHDHgzrJmnP6XfJopDoFE/uDLD9ZD9VDcLF ydMaNkSgT+LtELoCB0MDd6NCBIRi37rIN5PWGjm9PLDf6BF/CXJiG+dFQ3gi YRC1F7Eo8zu6X1xVMyPofTVJh3OXDEOoh2IpltG3PoBVrhGUMz08Cwhs88cl Hy2zOWGChkhGyXjUhwnBqI/5XlhvHiOoDEYMXyhu9D5MkEpqp2kQhUmYMkGA TZkOPXNdqbKGhC8MOFN2GjiLW6ejfACF5aEpo7yRwfB6JuHbVmL05UzDxsc+ xZltnMLG63ug56v19umxg27jrXBIceZ6B0rkTlEogqmsVNTxxYw7VwzY8tDE jIfqUYkQ+ZAwUiJ0ToZH2cQwxOf9hAUtPMrMtyITj811EQ4h0O4NHcpD2iyW h7X2XswreLmZDTFdSy1RvQ4ZAX398hgNsh4JRcMmPucyW2WowJdANPGpUqsT v0vF9qWk6eldc9t+VjXhnhZu+1FAJIBx7ZO65CGO70LHf05WgkgF4jRprQIJ T8dskJN0i7rdMaw6Ey3WxDOJCEJlecxeVHo7vP15fTum07wmDyRAud+ZunlF 468VWOI6aV3t0g8p3z5Kscb3XGQfjJ1w5TOqH267zyaO26fruPGtidobYvfp aMBkp+hg8OOh+8uDfZd3DyavnqF5o8LJ7lVuVmzqg/6yWP4UFZQOm7kwtXSD 5NhpFN+NrOGd+mmkOWPIwmknJLWExE1jDlDShqRhYTES3mZGYkD2HAyFgaFy Fi2IySAJiXBoaKBKXjgTFDIIcFJCkQJGBggygKAFBJZA0YGCCEIIR2w8MCkQ xShQJANCK4ir8bhSBhTJoXC4FigKFgQXZEIcIPBOEagYHHL2AWVrZjmvTn5R Hhfliw7dYIZ/e4niVJdnvb4FN7kbG7WV0mhVatu0R0JnltEkmg2otLYFwMii 2gpNeBseKywOlzpGjgJUTyPMfkQ+cNsD0LWR/vutiAsNiZKAKhmI1Ylv6fzm FO3AfhyNZUkX1HUzqWVPK358sJ3JyVFFmHq7u+TaNQgA+jA27koWg2sk5h2a QQJN+P5rDBOjYK4WUETdlTGGjWievpjUyKVvJAvbPkPMehBgmTfmFyfUsp0v JJMIQGtokZrfFX1NW+8r2bGfT3V5RfK2MXcFEpwriF7pewXhJgMXCBy1razC zMqhaUGzx7D4yQKZ72w1mTT522uUbRogpM9ZW1UXR1R5lzkR/nLSKj7FPY/R ad3tDia7Gh8pont7F6c1SjGW0eY5lK5aZaOUrffPm3kDzO/vDqfLwDDYdvN5 G5EJIlB3YI+JOD2KqNomkHDCDEaIIeVScToJct74h3hiCm7oSjkYFkMJfMQO fqXsmfP3QtofANsBZtgSjEkCJFErgGh3d+LHXSg8IfzknmnYuWN5bFcMMctD 09t8GfnQP/5k3veBzn5bMfeT1nwANiROeBxSGLE23ovIEfCAf47aBqqN5w+p MRMyyoZjmHwB9YeEk78H5GEMIKR7qqqqonyGc0wHn8KdZE8fZ/jnoePGL7q0 ekRKCRPQQwQhCca6A22r2lIp4XvtCbPeSYT2elMML43QoqwUjJgiFzuxbE8B IUsOJBgSHF2txMNfH8xX4TeAJIAYUz0t19jrYzMG/oG3ExqclU2ic4folFUp 7AfbSmIAQiDEP3EKeUCggM1LH0IQk4fFD2gL0wmWWW3eCFhq9Ghpir3UM7Zv C5X0lKhIoWoomD19O63cNBWhxqi2eKBcIjx9Ax5aD3aKGASBg3SJBCfjSpSQ YZOMtZGEYWoTu5zyPXuwSBmeuwP/8b1Ce7D3h2Ap5D/EOoOO4VfOjJDx1d9A KdH0fQ0Lmgyd8gV2Q2PPmXe6mVKqJz3tYvTsn9KUB1IP8zQEKQnSuLqaj5ud /CQlnEO37xeaHrYVhUFkOuJZlltoWUkPvTkOvVwfypyeLheQmrAuZ3H1n5rY EMBZo2GZdP7xzB8D7pOeLbobODw7qQ4osEAexFPZc1sR74sg+gQNJ8T391lX vn/1FefTsSHJThErW1kJBLSLruO82sQO1YGiSIeE5oucNTCxNtHAOZ2mlPCG gseJKUe0oqIVUIgHeH7QvnMczmDFHxBGzD62h+nlnInCsKk7cBSwEUFEvZ0w hprrHV0dGxs7hYv5bDsl0w6ptiUDw1vvE5ZLgp2HRToCdLJAhQ58wwwpaBiD czkTNoBjMu1XEz/kHwUD1klrzDNrfIbfa+T8taBguczvNM09WmVVsbuGSCmZ uEUGprfFMNeLDY3GEnpYKjbYmJmStGXamSl2pPmJ1nbGaJgdMC6GcSaw7A6h toDLVmaCggsOJatFcSVDMzwtsE5+e5tu6O+QZtUM5uEpmbBQQblQxmJUpHPB Ns9RfE77ya1MUaohhuHAgw2qv3BkzFEkWEmNeN6Mly0TKrePO+b8MaBTXB1K quBqnN0NrDk4FA5LM3VCjfSiMAI1RiKmIAGJJpbVrrRcHEIdJNTMvXl0yZvw eDlDkM6MISYMmAvGjEvrLmDFkLKI0YsxgaFInzjCkB1OnKpz6Uj6YkrVztMZ RL2iSxQTsbDzkdsjlxuZHDjYwsM7MY6bNkrJoSRhEmwcEHIrKCrY2o5JNKKq gbDTAccqctWs05hdDObq0rjMd73hXZlht3vWFdmUhNwQsNUhN6sCGoIQ4SEq wE5nic0N1IBc0Eh9m9ulG+ThgkKM0TTBBlyVKAgkTymgO6SWAluWhuhoaBB1 gokWQqIwM0iZ4Zh2E2gjqIocwa5iQOCEzYeHkE7qzhkNQ/PeQsWYXpM6fmwi fggaB31WhCKFsigQ7OiCmPojc4sAK5yBAIrISZCyoEKKV/tgDspA6lyybJR/ mKsWFyfLsc3haWkoLTmYfPRycSNcT0uTzJSh5IwrPAmxgFZpC0ALIh9WDSXC 5QYJZsFNF1oEyDw/svV56dLGTNHU0qSQOZyv1c8tHUBbFA72WAw9TiOnY+Ju wSPPu7W2d++r5FZJAhCSYesdQ3OTzmujRX7iH7yiJqoeE32XIHWG4xqwYYn0 iXRSkAp0m8x4DBMySUQ2U1qBbhSqvyRUXwxKE74KZFiEIaNI3CDAbdtgEsA3 hEJwAB7OWRvGYg7YA9fAwXOouGQ3PMkYfI4Wt/RPa3s6iuvJdpHu3IYWTEWD mCQE3XKCiASFgC5G0RCWtCXuAVA6oGoJs9tdSOnxA3icwPCL4zQw86ETkceC GHfgOTiUjYXl8ZmLwDOl4BPsK9hR2Osm0jqiwKoOsJggoesSUSaGUEgkFkBl ZIdbHIIGBFYq3NkiQpUOFDYmuT69rTLi22TsLHAbgHMJAzU2r9fIk64njRQ6 bnAhbcDs23SlgopLGGjaaAYhL/tjZbbSffQMQTBz9DOiBLNlb2BgwD6H+I4l yB3mbCafbrYUa6nNspwP5B5i87g7LtDTwh8glbFQ91qS11fSuMTdNi5BqLki hmou/IRTWzooLBuUpANLHLyKxtvtaU0GSWBAqil0VDGFAmKqQGvzc/lxPmh4 odgtepuRKnaS+ZvT5O3BgRLbRdJEXQX4u+6Nt73IWesL/HQGOPScy+T0It4X hUMbUFbeCPYbl3vN+x0Ya1MMSBjzGyJ5aNjltsfxE1Alea/FTkVJF7s6AvhD zn3aBHcBfQ9iWHep0OoiKZienV66H4gaP+yaAwhsh3H5nfAYjZX5oJ3kADsr x+cPcGf7F0pkiQCB3W4b/HCp/rgqqRg2T96+kx3+XUNOtXoNgf2tCURgkgEg RGMJIUCCQU4o7DmPLWB50Af/IMTmWuGCwIs2iZuoBsGPSdIROB3g7t4aExJS U1E8nkcQBO8/mRMLCmh56ATj0+GvL6pOx99bCQOAYjRZRNLbZs3FlbTU/og9 FPcp/j32C4fjQliecG0VJGyd8XdQwVSPByKH92iCJ6qmt0CgoPYYTJGwP3M+ 76TYTp8i5+KzogFswPtLVhBFPd4i+tRPD3WiV1Ce+/NwY5w7Z9TJECSLRUPK DTQ6gmJWD7/1oC6sLub8wzqaqwPoEkD7utyF/HbgIOnJCCDJEBA+ai+HUTWo vQgXFceroIhYDJo+aigBeAd+AOoUQCho7QvS6h7o/h3H33h8bWhiM8LVQSJW U4NBZPIrPEkOgGukHnqcOoHGB9AJouXg7wQq3TdPGgsWhKpoUMLDUDQl6lkm dCBxbHBSwHrCxZzaEoSwYYU3AQAxzD4bMrVtt5EvbhD1JACE1qghTRrjRMG4 Aabo8DiEiIaE+SLAQacS/OoaQgQgYeJCM3EIEMCdA31bynbZSSekDv/k5Buf DrS2giBbb8muW2nj4FIQmQSREYTMwwNKqqqr5iLV2eJjqoI6DZqG0XnZa5OJ nl5hjxMLexR39gqALZjXfD94Z92IHHQ6R2cSDD6x2kEwk7EtENmkMIDO7MM5 wk4QxCC8HW5nd4BrAxWtcqxNUeofX8EbHY7FfaWGgMQFOp7Q/8CxwFInXL2t Ek0IUDuLr1XzFIJtLjgSQkA5Vskn2NmKe+XEJmrEaCECcGVZfYWtA5TPWQ9w zChUdQaBEYZDKCTGyTO9HUkrNJUON5kKKoUpgGBTbrdUES0FQI97ViShTFaZ DR/wQSh9Xy5GuGnZ5JrLmimCdNtjJJVCmMEhZqiqo4IXBbRRf7B6nbgvIC1G FhGKRCCnEdkdvsOBCxaw3wmJsgQFEnn2+Kf8wZx2JUDLw6wicpV7oH+pK8i4 VYUEvEomIRBbRm4/ZEf/annNyies5+b1wHje1vCYqj5oH9Bi0XoueCCXVTXV wlYLgszobQ1hnHTOuCChmMSm9sU8KH+Cakau8IJ4mWGCQzQmmKltqPV5evPj tf7vj1DNpSKVo1SwBvlQkWEZviYDLpaN7yD79DhfdTWc8ubqm2HXUwEMhFC2 h7S7PnQcG1jJsXLMu3pw9emsF5W8k+JHfYC23MmpleoCuqo8PmMUHQ4hpTQB 5EAPIA09lhAuoQFDwAZO014nqPgnZK/ysvIep9xrpMFURf51Z7X2L8pNzMXI BD69bYH934NYTMpqCHSIc+a0df6HIgdqB84J7XoaKjKKTsNFERtBchkWAUfc +6B8kmo+uNf2fkcfw46cNtULNEqCv0H9oEPYsJzif9lFBkK6pFnXpTOzNEQG TDIgmeX1/Ih6ZUUfx/+7faVn/Yr89W1l/kLuSKcKEgBUIAfg --8323328-1168928013-1009629787=:2889 Content-Type: APPLICATION/x-bzip2; name="config-2.5.bz2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="config-2.5.bz2" QlpoOTFBWSZTWdbBDCoAB2rfgEAQWOb/8j////C/7//gYBp8AA+91AB8zAPk UTyOz53c4Aue3o6tPe9ydegoa9PW3e9pWuugadM7VtsdXcK1tl3uzY6drt3V 9u9pbsPbw1MQCME0AgmpPFTymTT0mnqeJG1PUeoAGmhDQTQImTQUwU9QAAA0 AACUAhBMkyDVPU9I9E0ekaAAaAAASaSSJ6hT9EwU9EaaBPQAIwQYBoIJKJMp 7UxTxGoPSekaNAabUMnqGj0gaZAEiIEBNNAUZQ0p+pGgaAANBoeoHz/v/b+T UWFQqqgtSsUFLSgoVm0MTo9Rr/mZ6tBf1dT8aaRVOJIRMcmku7L+7pMTi/i4 f23yAJzPrOWwihUgsqQUBZiDSwrLmZmF9e0MjFgatIpFFWGDBSsEtkuXGGIq ZYsi4wqAYjlhkTELlAcpBW2SZhQMVmCqkBSTGRtxMRZhlhg1DM8+V0ikmkMG QiyYklYZasKkWEFAWVERcSYmMArJiQhRgVUqGJhIRClKUYYj5rpNK1LWUVFk 0qAVjTGtzBtrUuZlLg0qqyOUomRKKRcrMayiKodzXGjR1Fy0zMKDhW5cEzED ExzMyuKJlVMYp53Trvyefovvf0T4/hx8vl/o1+xy0JCQe2Xf6dIP0eGGGbs4 +SETho+cdO5kPJQSlCZ5OZfC3HfMVyyicL+u1vu07Co4tL9PjoErgg/smT9i HyeyU2SdetS0/X3nf29nfm74U/pzxz9fi2Zl3Lk2Uz7FnaMt9Svwd4j1Nz5f nOtozgzt+PlpVbXv2YabUr8ru1wcjIwWw7U/roZNH1OP0L8S3tN9/yzDCq7U 0XHM/vq9bXalvjlHVevNUb3/m5ccDvKTEk3k6LT617Y438O27GzSGp9216Zw rKf0xnyye52wlvTSF93Hm/bZl6ztZw579aIKlJ/04DsOug4l0w6Iel7uZQEA RVxDbiQK7F85Y2N9l98m26uJqG1qzNrDek/FVW01jqefXN+ZWKhdF5U15X9Z s4hzD2HRxcYLcyq5mzxnXR2BznIySPNaLDNRClkasmZzZKWLRlMtYr0J3xy7 ed48Zx08p+c0wY7GPgR4um7bkV16E3py1GtTBdpLcz7sqDfweUigOxWjljF3 W58Zvlh5xm98dywnaY2R5eM07r64S26G3YU6bu3zpteUBP3Ws7At+r4kjPVe rINguse+/VwQzcXTBZdKNTSea9YiLjMt/I05LsmZBcMcna2hliUVd7rl3lN6 3zvZuTdoNeLMWhYivuIsCeszoSEgyZpm19iEhIGw062+DIFipe0MTo5uZ98n mu1fFqSBAs+hBJjqqv3n7Jdq83JC3ZH/Q4R0j2fCsdDP6Pocjatot6/VLx84 ot5dJdqu31w1LUTMClpccYVSVZxae48VCeOhNeU2uzfx6tHi10eFiNZHj8v3 VJtDWzQnvl9jGWX298ET3fxx87x+asJzwtlr8v4GFtPcSn38yCnKDZ8noGgk hy7Y+23wiKxaXzLyJnt3xozkY4fAzIdI8IFYPNX4S9MLoXMEiz7tk7sH3Szz k1uv56+mrn+xRM2kzLAd1sbvbLvgzXjnPmpjap4EiiWvPjDEESiAHWt0AGld D0UffYpLvKri1h/Lw+EF48PXJMSEZUPc7QeH5wSfWw3ptsUqNChgShJwIEoF v3OoKddixODKK5XROla3axK6CMzSWE42MQWvbfcPnAl7VqEvSYVdMJdrY3ae ELc8HG8UyinAzIiIJq3JUAer3KNFBTguh4LV3azTKggo4puqz2X1qFmeg0K0 7LJj+7ikr1pgOeV82UWUKiJvPbdZLez9HilYbYdptFU9/K01oRMzdWUJXq3b UebeFVPWOqAVUFRwosAM6ICUpSQh+PUBTVv8eddr1Ihmr5rDBMPhVMoR6Tuu k05NzjiIhoIgASHO3dfXUd7PUMTqAq3Py4uREmsvT2W8N9nlGMw8+G+XM8Ie F3CV0WYdaGXHpeV+0a8c73o+d87NEUwSJT2rYtBd2HnfBG/N3TvjeLoZpnH1 a9M8XvGYcYbdtIz/R48XjDCGDhyysoehNpfwuF4lFjyWc9oQNdCTGOFiyr0r ofTm18LHqtuNNmV5dDd1P2STNunhnBWbDpzbnYn19rhpEdYWzWbJyXTRofw0 WbrHK6UlPaChUU949fIYitYv1vterVqRV1+gcsn0BQEnykgo4wSy6qqeOemI iy7qm6quokzj06qf1OX1oWk5pXFFAIZ8MLtXWkV8jpVCIAigoQR3nHOWIMh5 2RV085TfiMCRLFoZpvjCjCRIM+41NykGZmU3p0TXWWjvt3lZL6EAYTrGRKjJ fSbMloCgAgBwZHNk4jciQ+9W0LXBoLQURH1VPLOzb6yvJZnWwii6qcspAYVx WAbV3aF5MaEu5yJl0MAqCdMc5qVygRAls56yl3Is1ztGtod22wdGKWHUL8vH FZPPuDpuGqCFpSs3734Jol259/V3gtAfRv1BoMQBTDNc+tajLPRtp32qTlAU jTq58DfSMEYdfRmALMZUVZCLCIPdPl253d8O3ON3vTz8Xp5vLo9DY9lTgxEN 9g3IpcWFg8ymc/C77RtcHlXu5auiVXzlEIhC0tOPx570PmFKFN2KNpxoyuGK d+pTXI+o9VQLC/JtibA4SFiFR0aCzW0GmkSNjTnG2K3ElAr2NqDoYaEczd2v XekZDT22ev/KALJFiMWEUEVkRUUUiIooKRRSKIkRkRUjBQYRSIwiQWSMYpEi CsUgxFVGDGSLCCiiKiLCLIRFVQWCMgsFURWSKxUUjGRVVRQBYsgqxRGDGRBE ZEQioqxRRCCigqqQWQFhBiQRCLJFAFUioxYKCoICJIRGIixRBgIgMgjGFUvX 4osxqfwIj9WfYDagobB1XWA1aX4fHCCIkS7KqTfmaxXzSKVIlKQ5PUsFnFkp LsaXhQ2Gdsy/x1G5Als1rRafV8dewXznY+vrDR6NmmGXPWBMnQ5KC05tNq9d cabfDgWsDGNSNKkMCQmrQ1EDq2QLzl06OswLBpA+kiUt4mACRqrEFUImCrsQ vjpvvjB37sHNUQAwqmeZ3egjFZVDnB0oUAxSLoI8NXzcUIytS7isNNp8IEeo K6IzqqEvDMZQhGzzf3oRmywRgWIhHDRm1d6+YAb85QFbRVPVoJYvienjqd/H Z1I6qtN9HOvfmXlfLyifwOOtYVcJqiFx3Lt8tdGDgio2ZRZRPzlV+fa3zSWn oiKlZ6ZzONh3vlVj1yeJQQNLOtQCL9gBFE6UbnTK5iSCc1skkt+O2Q8Gg8+J 93ST5BpiYFBhm4PV0JScp2wXGIdhBCWxbePNfObqj5XXkKNiPM7JsmpRESiY Cmk/asmgBqVfvPrXjdOd9X0YLKXkmuRMoApt9FcwRpFQyDXKogsUQ1s1tvAU CBu6+fUnHkyHG9/QhDm8WlVFgCvZGCYYxbndhz7VvfrYP0t1IULoUQCAGJKA Fq/gyV+J60c9hIEhM6HuBdKbE6fropf1hDKEKRAFygSRDnLqBMok5L60Eq7v 32a4t769/Go19sa5zTaWSJkTe93En2IQV6OFKH0HsQMB0NdWKqDrQ+WS1r32 fF4vTcobkWcb4jOh8NVmiEp2yQ0T8zWsDLsZW2KYvBthIQm0gQ2AkmwAFhCA oiBAFJCLCYwkA6dfhtozUXLdImNDIpR9IWAZINssQNq2vYlIV2REDpe+4SGK BLIseDJXC1WTdhm30me3wILcRjxeb5VU9ztFnTXdA2lu12LWLMhtoTZfwoDg AGIgYs9iclN635xT8H5OI3voaS9PCM8K+gSPMNmctxapl1PvCETskEI6smyj p6NDKiXj11+aGDfPxAWxtfAkCQvRj5zPOdg0y4K569L5b14FpfxQl/KfmnLM PUr6ZzmGpIAby2woZE8IHfDb5S5YglVVVCOBEoiZmJw5sd848ZLtMO0JHY2Z Dh07lGNKdiDrwQZt2xZnWv3GGaSDEbgwQVV0EIX2M4nfnpQ79zvs57D+0kmU ZmGRRk2XvgpQpTTk9sWbY/QQQDYtHVqU0N6OszMNCzcOzE47LxyW2MCeZDbh y6d/fW+GRT4X0R7Tr5j0W3pDZQYS75PpnuetS7QksBrtAb6fC5vCb328eJgp oYxOeeTSjN05sKuiNLqNZUsMRSo5Q8WboBYYk0m4HF5iWKJ+K55+32+rONS9 K5q2uySSnvNSYHA9K9yhR6fkELucni6zq5lCDpluEJa6nQMsn5yxkhHDQmUk lb7XxOVCvZV6qSotJmrtrSRzj57aG7JdkY7eeldS2Nfdw63zFXxi2dUQl1QV CccJC4lUZKiDyIKO1jSYFlJIltLw4LFb2aPIhYg254EpZKprm7k/OA3xcAcg gsgjRxy607rPPeThPU/Ow826IwLCodvma9x5OgqcWPL20OW8Zy6+HddRWi1V Gl2Z+LOylVOoPYXtgB0hBHmSeblWZB6TUSbQA63PMR9PjJX/PW/jORvFHkL2 1R0Yg2LzUkCQlhkgwrwdOLvtlud+3N43jGO7CBlwEXZSIVWHdE1ACxQlqXlK V6xMVgaKnWTparuNRY4v+BazZ2cQlAUcuRQYW0tioHdD2955fHMDttKzm6M5 OvXhNu3d1KnZ+YPNDd6B4cXa82G0IZfLSR65dyKt59SiaydfQYxqrGEPOvjO wGbMUonLi2GC76J7rXggSBIUZb2zrvlCId33C0VGDYMZjjz3pppoFncpkcw4 1FDemDo02QDcDfZNRvj5ZQILAY2fC1JKLLjr8cTagR1AF5uxejnCwbd+jKdP Jrbx3Lws6/DR3nBpsmccrg1NZU01YeW6fBOjmN+Y68xY7V6yS8a4HlIzDwdg +tt0I81EZDshGc5TPaIvGJ4ldMbSvf2IXfaNGFGBVy/GpoSmWhAum8I68BvO sE/gfSevdpfTHd4a8RpaJZDOWFTnYgxREclNc6cAyzYDvEFHxmmYYlPmuTkx iZBZzIGqihmxU93MUIccBN8vix0vpj2AEZWddCO0IrEyxM+PQtvXJTGl9AOp RRFbSQ7AuwYqelCryUnkhWVcKGO5XzjQCvjId8pgzrdhMcurAKfXRB+W9W0x +TaKhc1kgnxqtCVkQrRZqRMmNJkk+IVsOriMKhEIAclGyy2gkUqc+vLMnlkd DFcPGqtRKs5ou1OuGqfz2xOsyWKSO3vnRiV35i96lesGz6Bd1c3JGpomJaY3 EiqV6s+q0iRx9F/NOXGb3+0HneLEA++OHJ4I4fmj86eUqcE7WhD6ZaZFyLKa Lo4yRU9ZiG1aEay1wQreBIMZEQUpcqTdVwRSyi71dJ6d4sKbvO8r0ZAhdjSK PktGEA27stMdHXzkT8SoQhavplvNhyFWmwA7KaVtkqddKW0On2C7gwA13vDI I52gLQ0eAhCJBHZgBF0DVGJ2jYohUZojr4sUYAQ9FG4QV5q4mRaahZyy9os6 1k+aUD4BnthmhSG8b5U4eOoHDReK91DGboc/cdsIW1AOjHpBmygLDIDRlmKW eBdej5jq9cb8wzvQkR89aCktYCisK1Q67zIf4z0RVinI3xvnSJFqXYlKH6lv TXYjU0ByK7ZtICRSR7mbcidMzDbKnwxKmhsNOc2DDhGUSZ8BxjVWWxVSLyxF jZRKRD6jIpy5xHZM3vBbpqh5XVNtRCydNwbj59n31L4lTebEOkyNau+xyZ/W VL254kHBMKE4NmWBusBRUvRcZdWbHYwxDMqmQwS+HSHRk1Wah56mkipQep4p mpbYprAvmDblvE5309SWdJunZR0PqKGA0yCjv9MveZaUWJ7aux/BWuljltJI khlFASbRJQjfc+0wVA4cRBw0ICmQoOBWO1aRVWanqi9EkrvM2YWOMVosqHAM nMLi2ZitnLdk0u0EJBtaDlnh7GiCOsLOd+AlN2+syMBkYOJUWEFkUFgNrrAf UqitYNM4ONoNYbjpWCyvaaeYOXqW9Z/nsfSvfyU381u5vCeyPgdLrS+RXWzz x+Qmi0AEnYWNPdDOz3gk8vEhBHdDay30gyPtSRv5/YzOLVK3u4Y4ysFOdklE Bt6fP7G3RXst7OqnN2Z1HYmbDJmsYxjKYXoUINkpnVJPj3ztqB57NFn621f3 FyNt0jPtfBP4+7Xa2gjtz9hfaqFuWgOxLrg7xfSNJhXidD1ibVZKHyS6TnUm cGg8YohczBZJbNM98ryWQGPDKt3DHdcMX9LoiIlqY46NwF51o1bLSWNCsnBQ oJXBUDjE95J8qbpTTPFLIECzwPIUyu1GVZVPUY6Ll674ng2olR8zyhfJF5vc u0AU2vlrtjCVfUduYVXgokkZtDYNoky4167nSxlvFui0Vvq8IEGjshSq2I3Q GHwO02xHvv1sJAma1VUjpzO8+KdiiIGfVgvVdWpDNy/ImM8EZH2ETIv0VJcG 4gMyFSVmfWoXj64IKa8HoQGmAmcw4+GQRXRBDJcmajVMJaQjw6zDpW1ATYG1 PF7usJNoabGPeCH9oSwb7Em/Ml6IAs/fHrFKq/qRHbOOGB2d372ijSAnMFF+ 77RYojFpyKKnOgg5RtnMF+F+TzNKYtlwMO0iYupLlPHOC6lls0YtjalawqlZ kjSXiht7xN2bbQM3cHJGnSiIfPEIOaKDNh1GcsQOYXR6IqTvQSDW8HZppPtW mCB6+jX8WrbnHxkImq4rGBPqvBCIxjhRGG7euRXnljZ9/GaAX38Xi3usAygU wY11k49MOjnWvRqF+63r4y40KEgFliMaO3MM/kKM4BF+nhmlu5tlqUr7RVdN mHv2yRSxEP1WDzxR5XF1WQT5ZB9OdrazaEEEvOz1zvRZIvTLuwMoiKqDkYzm +VED+2L2Te7O+kGbQCwPztiXVzSuSDbPFGKtoXCd/aYch/AdsC6wbFFOiK/i 3lNHgRHD+NJCVA6j5rAamgGc2aEBFJ5Mbd+2q8dsaN425kswgEu/VhR1Tp0Z hcy5y1SMW33dAAvfWog+87oUyKzt+7e4ry0j37BqdcPxjttyJvQkHzd4Rw4e HNiGGLMT/t7P3cn9nXljSKNHiec5K1vYk+n7TRmGx71K5YuJmqJekXk4l0sd X/J7Nf7IGv8fd/MZUKzIrW627z06oF01pqUXufsQl5ZY1hFyhPEH5+uYasgL 0uahElEX/KEhIM1895glzlY3Evvn5XF8likB7oQfPxWZDGr608EtRWOcj5up Sj9Kq94JP18d/Uq+slOHJK19MScoKUFKA/27/odlAwYAzEdjQkoAXt93Lo9U 7vQutYj8BD3TLBX520/cjVghGP49I10g3vRlU3DNYR1oM/K1Jf1qFve81KqC IIgTSVhWFZTt+3w04mvkd7/Ff0+EQQPYXMuDS9A6dYveJ2oKkClkSSEgo05Y /Pg11DPrzqkj79rpI1wM2tXFG7QR5hR84OKR4+5OCgO+CRzQf0RUJX7zRCBO 0R85/rlRMF2dJkmZhP6aISEg06CSEgczaLaPsFxI/NykIyQjEAgEEGxnE/+0 QkJBNS3XM0Xr4PGOkWxe37RWVlUYgWu+b3LIQKX/PcaSx/7dRyPyjHpVPYki GME6IuLq3KOmWdQjENakooQv7Pm0+q0hIJbuDjXDax/fpqVv/i7kinChIa2C GFQ= --8323328-1168928013-1009629787=:2889-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 08:02:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 08:01:58 -0500 Received: from garrincha.netbank.com.br ([200.203.199.88]:54535 "HELO netbank.com.br") by vger.kernel.org with SMTP id ; Sat, 29 Dec 2001 08:01:47 -0500 Date: Sat, 29 Dec 2001 11:01:29 -0200 (BRST) From: Rik van Riel X-X-Sender: To: Linus Torvalds Cc: Alan Cox , , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , , Subject: Re: State of the new config & build system In-Reply-To: Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001, Linus Torvalds wrote: > Having per-function comment blocks, in contrast, makes sense to have > inline: > > - you read the comment when you read the function > - you might even update the comment when you update the function > - you have a reasonable 1:1 relationship. Personally I'd like to see each C file have a header like this too, describing in a few lines what the functions in this file are supposed to do. This should make it easier for people to figure out not just what each C file is about, but also if they should spend their time wading through this particular C file when in search of some piece of code. regards, Rik -- Shortwave goes a long way: irc.starchat.net #swl http://www.surriel.com/ http://distro.conectiva.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 08:33:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 08:33:07 -0500 Received: from garrincha.netbank.com.br ([200.203.199.88]:53512 "HELO netbank.com.br") by vger.kernel.org with SMTP id ; Sat, 29 Dec 2001 08:32:49 -0500 Date: Sat, 29 Dec 2001 11:32:32 -0200 (BRST) From: Rik van Riel X-X-Sender: To: Keith Owens Cc: Linus Torvalds , Legacy Fishtank , , Larry McVoy , "Eric S. Raymond" , Dave Jones , Marcelo Tosatti , Subject: Re: State of the new config & build system In-Reply-To: <7861.1009589244@ocs3.intra.ocs.com.au> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 29 Dec 2001, Keith Owens wrote: > ps. I don't want mail discussing individual bug fixes to mkdep. Code > that does not fix _all_ 9 bugs listed in makefile-2.5_make_dep.html > is pointless. I guess you presented a good point to not ignore bug number 10 (the speed one) either. ;) Rik -- Shortwave goes a long way: irc.starchat.net #swl http://www.surriel.com/ http://distro.conectiva.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 11:29:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 11:29:01 -0500 Received: from bitmover.com ([192.132.92.2]:2471 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 11:28:42 -0500 Date: Sat, 29 Dec 2001 08:28:38 -0800 From: Larry McVoy To: Anton Blanchard Cc: Alan Cox , Larry McVoy , Keith Owens , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011229082838.A16667@work.bitmover.com> Mail-Followup-To: Anton Blanchard , Alan Cox , Larry McVoy , Keith Owens , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011227180148.A3727@work.bitmover.com> <20011228094318.B3727@work.bitmover.com> <20011229092437.GA1295@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20011229092437.GA1295@krispykreme>; from anton@samba.org on Sat, Dec 29, 2001 at 08:24:37PM +1100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 29, 2001 at 08:24:37PM +1100, Anton Blanchard wrote: > How large is your core db stuff? The thing I like about tdb is that it > is very simple, only recently growing over 1024 lines. 1404 4736 32921 mdbm.c -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 12:12:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 12:12:07 -0500 Received: from hog.ctrl-c.liu.se ([130.236.252.129]:51216 "HELO hog.ctrl-c.liu.se") by vger.kernel.org with SMTP id ; Sat, 29 Dec 2001 12:11:55 -0500 From: Christer Weinigel To: kaos@ocs.com.au Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org In-Reply-To: <7974.1009590240@ocs3.intra.ocs.com.au> (message from Keith Owens on Sat, 29 Dec 2001 12:44:00 +1100) Subject: Re: State of the new config & build system Reply-To: wingel@t1.ctrl-c.liu.se In-Reply-To: <7974.1009590240@ocs3.intra.ocs.com.au> Message-Id: <20011229171153.49D4C36DE6@hog.ctrl-c.liu.se> Date: Sat, 29 Dec 2001 18:11:53 +0100 (CET) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Keith Owens wrote: > Run make dep after - > > A change to .config. Ok > Any source change, it might have changed the #include list. > Any source or command line change that affects generated files. Not really, I only need to run "make dep" if I change a #include or mess with generated files somehow. When I'm hacking on a driver, I think I'm supposed to be clever enough to realise when it's time to run "make dep". When I apply a patch from somebody else, I usually don't know exactly what has changed, so to be on the safe side I should always run "make oldconfig && make dep" after applying a patch. If I move the kernel tree so that the absolute paths won't match any more, I also run "make dep". > How do you automate that? You end up saying that you always run make > dep. I don't want to automate that. In my opinion trying to automatically figure out when to run make dep is overkill (except to run make dep a first time when it hasn't been run before). Anyway, from what you have said it seems as if the slowdowns are due to two things, checking dependencies every time and doing the translation of absolute to relative paths. I'm not arguing against kbuild-2.5, what I want to say is that I think that not all of the nine bugs you mention are showstoppers. If you can get kbuild-2.5 into the kernel without the absolute->relative translation, why not do it? I just noted the option: make NO_MAKEFILE_GEN=anything which allows me to test things rather quickly (does this avoid the absolute->relative conversion?) so it seems as if you've fixed this already. :-) One thing I'd like to change though: Error: the previous kbuild used NO_MAKEFILE_GEN, install is not safe You must do a clean kbuild without NO_MAKEFILE_GEN before doing install I don't care that it is unsafe, if I know what I'm doing I don't want the computer to say "Sorry Dave, I can't let you do that". My current way of working with embedded systems is to install etherboot on the machine and the suck the kernel over tftp and mount the root file system using NFS. The way I work is usually: change a source file (e.g. drivers/char/scx200_watchdog.c) make SUBDIRS=drivers/char modules make INSTALL_MOD_PATH=/export/nfs/00601D1D1D52 modules_install reboot the target system and test the change Of course I could just copy the module by hand, but when there is a whole build system that does things, it would be nice to be able to use it. /Christer -- "Just how much can I get away with and still go to heaven?" From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 14:15:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 14:15:20 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:5381 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 14:15:14 -0500 Date: Sat, 29 Dec 2001 11:12:33 -0800 (PST) From: Linus Torvalds To: Legacy Fishtank cc: Benjamin LaHaise , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , , Subject: Re: State of the new config & build system In-Reply-To: <20011228195914.A14127@havoc.gtf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2001, Legacy Fishtank wrote: > > A per-driver metadata file is IMHO clearly the preferred solution. Note that it doesn't need to be per-driver: there are good reasons to have "combined" files too. For example, things like "architecture config" could all be in one file, along with similar drivers (ie "3com network devices", whatever). Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 15:27:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 15:26:53 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:24070 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 15:26:41 -0500 Date: Sat, 29 Dec 2001 12:23:37 -0800 (PST) From: Linus Torvalds To: Keith Owens cc: Legacy Fishtank , , Larry McVoy , "Eric S. Raymond" , Dave Jones , Marcelo Tosatti , Subject: Re: State of the new config & build system In-Reply-To: <7861.1009589244@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 29 Dec 2001, Keith Owens wrote: > > Yes, some of the problems with mkdep can be fixed in the current design > but there is one problem that is inherently unfixable. make dep is a > manual process so it relies on users knowing when they have to rerun > make dep AND THEY DON'T DO IT! Don't be silly. Make the dependency file itself depend on all the files it describes, and add a makefile rule to re-generate it. Poof, problem gone. > Dependencies _do_ change when your .config changes, Only if you do them wrong. Look at mkdep.c - it statically determines the complete list of header files that _can_ be included, and does not care at all about what config options there are. > that are included varies. gcc -MD gets this exactly right, gcc knows > which files it read. Bzzt, it knows the subset of files to read, nothing more. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 16:25:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 16:25:30 -0500 Received: from cpe-24-221-152-185.az.sprintbbd.net ([24.221.152.185]:12456 "EHLO opus.bloom.county") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 16:25:18 -0500 Date: Sat, 29 Dec 2001 14:24:55 -0700 From: Tom Rini To: "Eric S. Raymond" , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> In-Reply-To: <20011228141211.B15338@thyrsus.com> <20011228173151.B20254@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011228173151.B20254@thyrsus.com> User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 05:31:51PM -0500, Eric S. Raymond wrote: > When I talk about "rules that use architecture symbols to suppress > things like bus types" I have in mind things like this: [snip] > unless (ISA or PCI) suppress dependent IDE Just a minor point, but what about non-PCI/ISA ide? > unless PCI suppress dependent USB HOTPLUG_PCI And there's hope this will die soon too (USB) ... > unless (X86 or ALPHA or MIPS32 or PPC) suppress usb or SPARC or SPARC64 (iirc) or ARM (once !pci usb is allowed)... > unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent IEEE1394 Wouldn't the experimental be global? And maybe the PCI too? > It seems to me *extremely* unlikely that a typical patch from a PPC maintainer > would mess with any of these! They're rules that are likely to be written > once at the time a new port is added to the tree and seldom or ever changed > afterwards. But they will be modified for new arch X, or when constraint X (like PCI) is removed. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 18:01:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 18:01:29 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:29670 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 18:01:08 -0500 Date: Sat, 29 Dec 2001 17:43:54 -0500 From: "Eric S. Raymond" To: Tom Rini Cc: Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011229174354.B8526@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Tom Rini , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228141211.B15338@thyrsus.com> <20011228173151.B20254@thyrsus.com> <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net>; from trini@kernel.crashing.org on Sat, Dec 29, 2001 at 02:24:55PM -0700 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Tom Rini : > > unless (ISA or PCI) suppress dependent IDE > > Just a minor point, but what about non-PCI/ISA ide? The CML1 rules seem to imply that this set is empty. > > unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent IEEE1394 > > Wouldn't the experimental be global? And maybe the PCI too? I don't understand what change you are suggesting. > > It seems to me *extremely* unlikely that a typical patch from a PPC > > maintainer would mess with any of these! They're rules that are likely to > > be written once at the time a new port is added to the tree and seldom or > > ever changed afterwards. > > But they will be modified for new arch X, or when constraint X (like > PCI) is removed. Yes. -- Eric S. Raymond "Experience should teach us to be most on our guard to protect liberty when the government's purposes are beneficient...The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well meaning but without understanding." -- Supreme Court Justice Louis Brandeis From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 18:12:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 18:12:38 -0500 Received: from cpe-24-221-152-185.az.sprintbbd.net ([24.221.152.185]:59561 "EHLO opus.bloom.county") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 18:12:24 -0500 Date: Sat, 29 Dec 2001 16:12:02 -0700 From: Tom Rini To: "Eric S. Raymond" , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011229231202.GE21928@cpe-24-221-152-185.az.sprintbbd.net> In-Reply-To: <20011228141211.B15338@thyrsus.com> <20011228173151.B20254@thyrsus.com> <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> <20011229174354.B8526@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011229174354.B8526@thyrsus.com> User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 29, 2001 at 05:43:54PM -0500, Eric S. Raymond wrote: > Tom Rini : > > > unless (ISA or PCI) suppress dependent IDE > > > > Just a minor point, but what about non-PCI/ISA ide? > > The CML1 rules seem to imply that this set is empty. It's not. In fact, I don't really see that implication either. There's lots of drivers hidden under a CONFIG_PCI check, but nothing under an ISA check. From ~line 104 to ~136 I suspect are all non-PCI and non-ISA chipsets. > > > unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent IEEE1394 > > > > Wouldn't the experimental be global? And maybe the PCI too? > > I don't understand what change you are suggesting. unless EXPERIMENTAL and (((X86 or PPC or SPARC) and PCI) or ARM) Since the experimental tag I believe would be a global thing, and I'm thinking that ARM probably implies !PCI (since it does so often, but I don't know for sure..). > > > It seems to me *extremely* unlikely that a typical patch from a PPC > > > maintainer would mess with any of these! They're rules that are likely to > > > be written once at the time a new port is added to the tree and seldom or > > > ever changed afterwards. > > > > But they will be modified for new arch X, or when constraint X (like > > PCI) is removed. > > Yes. Not typical than, but it could/will happen, from arch maintainer Y. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 19:22:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 19:22:36 -0500 Received: from caramon.arm.linux.org.uk ([212.18.232.186]:4879 "EHLO caramon.arm.linux.org.uk") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 19:22:30 -0500 Date: Sun, 30 Dec 2001 00:22:03 +0000 From: Russell King To: "Eric S. Raymond" , Tom Rini , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011230002203.E12535@flint.arm.linux.org.uk> In-Reply-To: <20011228141211.B15338@thyrsus.com> <20011228173151.B20254@thyrsus.com> <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> <20011229174354.B8526@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011229174354.B8526@thyrsus.com>; from esr@thyrsus.com on Sat, Dec 29, 2001 at 05:43:54PM -0500 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 29, 2001 at 05:43:54PM -0500, Eric S. Raymond wrote: > Tom Rini : > > > unless (ISA or PCI) suppress dependent IDE > > > > Just a minor point, but what about non-PCI/ISA ide? > > The CML1 rules seem to imply that this set is empty. RiscPC: CONFIG_PCI=n CONFIG_ISA=n CONFIG_ARCH_ACORN=y Yet, we have in drivers/ide: if [ "$CONFIG_ARCH_ACORN" = "y" ]; then dep_bool ' ICS IDE interface support' CONFIG_BLK_DEV_IDE_ICSIDE $CONFIG_ARCH_ACORN dep_bool ' ICS DMA support' CONFIG_BLK_DEV_IDEDMA_ICS $CONFIG_BLK_DEV_IDE_ICSIDE dep_bool ' Use ICS DMA by default' CONFIG_IDEDMA_ICS_AUTO $CONFIG_BLK_DEV_IDEDMA_ICS define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_ICS dep_bool ' RapIDE interface support' CONFIG_BLK_DEV_IDE_RAPIDE $CONFIG_ARCH_ACORN fi So I guess I've found a bug. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 19:28:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 19:28:34 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:32743 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 19:28:20 -0500 Date: Sat, 29 Dec 2001 19:11:01 -0500 From: "Eric S. Raymond" To: Russell King Cc: Tom Rini , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011229191101.A10380@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Russell King , Tom Rini , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228141211.B15338@thyrsus.com> <20011228173151.B20254@thyrsus.com> <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> <20011229174354.B8526@thyrsus.com> <20011230002203.E12535@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011230002203.E12535@flint.arm.linux.org.uk>; from rmk@arm.linux.org.uk on Sun, Dec 30, 2001 at 12:22:03AM +0000 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Russell King : > On Sat, Dec 29, 2001 at 05:43:54PM -0500, Eric S. Raymond wrote: > > Tom Rini : > > > > unless (ISA or PCI) suppress dependent IDE > > > > > > Just a minor point, but what about non-PCI/ISA ide? > > > > The CML1 rules seem to imply that this set is empty. > > RiscPC: > CONFIG_PCI=n > CONFIG_ISA=n > CONFIG_ARCH_ACORN=y > > Yet, we have in drivers/ide: > if [ "$CONFIG_ARCH_ACORN" = "y" ]; then > dep_bool ' ICS IDE interface support' CONFIG_BLK_DEV_IDE_ICSIDE $CONFIG_ARCH_ACORN > dep_bool ' ICS DMA support' CONFIG_BLK_DEV_IDEDMA_ICS $CONFIG_BLK_DEV_IDE_ICSIDE > dep_bool ' Use ICS DMA by default' CONFIG_IDEDMA_ICS_AUTO $CONFIG_BLK_DEV_IDEDMA_ICS > define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_ICS > dep_bool ' RapIDE interface support' CONFIG_BLK_DEV_IDE_RAPIDE $CONFIG_ARCH_ACORN > fi > > So I guess I've found a bug. I have removed the constraint in question. -- Eric S. Raymond Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, "Abbey's Road", 1979 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 22:34:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 22:34:32 -0500 Received: from mail.mbi-berlin.de ([194.95.11.12]:4047 "EHLO mail.mbi-berlin.de") by vger.kernel.org with ESMTP id ; Sat, 29 Dec 2001 22:34:11 -0500 Date: Sun, 30 Dec 2001 04:34:58 +0100 From: Viktor Rosenfeld To: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system Message-ID: <20011230043458.E2434@bart> Mail-Followup-To: linux-kernel@vger.kernel.org In-Reply-To: <7974.1009590240@ocs3.intra.ocs.com.au> <20011228230924.C7801@havoc.gtf.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT" Content-Disposition: inline In-Reply-To: <20011228230924.C7801@havoc.gtf.org> User-Agent: Mutt/1.3.23i X-GPG-Key: http://www.informatik.hu-berlin.de/~rosenfel/public_key.asc Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org --ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Legacy Fishtank wrote: > Kernel building is not for newbies. Crap. Back in 1995, I had to compile a kernel to get Linux installed, because the packaged kernel did not include support for ATAPI CD-ROM drives. I had no Unix experience whatsoever, basically what you call a newbie. And, no, the situation has not changed. There are - people/cooperations without Linux kernel compilation experience, who might need a feature that's only available in a development kernel, - *newbies*, that are generally interested in learning Linux in all its ways. Your attitude strikes me as unnessicarily elitist. Cheers, Viktor --=20 Viktor Rosenfeld WWW: http://www.informatik.hu-berlin.de/~rosenfel/ --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8LotikWI06CMxQ0ARAv4jAJ0bICBVUGXUendSfDT/G/Pgfj2dbQCeLbdi krJKqbCiEVipfab1GHnW08U= =3U7E -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 29 Dec 2001 23:24:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 29 Dec 2001 23:24:45 -0500 Received: from ns.suse.de ([213.95.15.193]:37131 "HELO Cantor.suse.de") by vger.kernel.org with SMTP id ; Sat, 29 Dec 2001 23:24:30 -0500 Date: Sun, 30 Dec 2001 05:24:29 +0100 (CET) From: Dave Jones To: Viktor Rosenfeld Cc: Subject: Re: State of the new config & build system In-Reply-To: <20011230043458.E2434@bart> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 30 Dec 2001, Viktor Rosenfeld wrote: > > Kernel building is not for newbies. > Crap. Back in 1995, I had to compile a kernel to get Linux installed, > because the packaged kernel did not include support for ATAPI CD-ROM > drives. I had no Unix experience whatsoever, basically what you call a > newbie. Things have changed dramatically since 1995. In particular, distros got a lot friendlier to install, and customise. If theres a valid reason for Aunt Tillie to rebuild her kernel, it means her distro of choice is doing something wrong. > - people/cooperations without Linux kernel compilation experience, who > might need a feature that's only available in a development kernel, > - *newbies*, that are generally interested in learning Linux in all its > ways. > Your attitude strikes me as unnessicarily elitist. Dumbing down the learning curve doesn't necessary make things easier for people to learn. Reluctance to read documentation for eg is something that will plague us no matter how simple we make it to build kernels. Dave. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 07:06:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 07:06:03 -0500 Received: from ns.caldera.de ([212.34.180.1]:43705 "EHLO ns.caldera.de") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 07:05:52 -0500 Date: Sun, 30 Dec 2001 13:05:29 +0100 From: Christoph Hellwig To: Kai Germaschewski Cc: Linus Torvalds , linux-kernel@vger.kernel.org, Keith Owens , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011230130529.A27210@caldera.de> Mail-Followup-To: Christoph Hellwig , Kai Germaschewski , Linus Torvalds , linux-kernel@vger.kernel.org, Keith Owens , kbuild-devel@lists.sourceforge.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kai@tp1.ruhr-uni-bochum.de on Sat, Dec 29, 2001 at 12:44:06AM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 29, 2001 at 12:44:06AM +0100, Kai Germaschewski wrote: > But yes, it seems possible to replace the -MD dependency file, which > depends on a specific config, with a generic dependency file, which knows > about our #ifdef CONFIG_XXX and translates them to the corresponding > ifeq(CONFIG_,) Makefile syntax. It'd make an interesting project, but it > effectively means re-implementing a C preprocessor. Michael already wrote such a program. It's part of the dancing makefiles patch, which btw is a kernel build system that is not only correct but also faster than the old one.. It's scripts/mk/fix_dep.c in a kernel tree with the following patch applied: ftp://ftp.kernel.org/pub/linux/kernel/projects/kbuild/dancing-makefiles-2.4.0-test10.bz2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 08:41:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 08:41:42 -0500 Received: from femail48.sdc1.sfba.home.com ([24.254.60.42]:35737 "EHLO femail48.sdc1.sfba.home.com") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 08:41:26 -0500 Content-Type: text/plain; charset=US-ASCII From: Rob Landley To: esr@thyrsus.com Subject: Re: [kbuild-devel] Re: State of the new config & build system Date: Sun, 30 Dec 2001 00:39:43 -0500 X-Mailer: KMail [version 1.3.1] Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228141211.B15338@thyrsus.com> <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> <20011229174354.B8526@thyrsus.com> In-Reply-To: <20011229174354.B8526@thyrsus.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: <20011230134125.VUHO28486.femail48.sdc1.sfba.home.com@there> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Saturday 29 December 2001 05:43 pm, Eric S. Raymond wrote: > Tom Rini : > > > unless (ISA or PCI) suppress dependent IDE > > > > Just a minor point, but what about non-PCI/ISA ide? > > The CML1 rules seem to imply that this set is empty. There are, apparently, paralell port IDE devices. I've never seen one, but we've got drivers for them. See PARIDE and paride_devices. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 08:49:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 08:49:33 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:34567 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 08:49:19 -0500 Subject: Re: [kbuild-devel] Re: State of the new config & build system To: landley@trommello.org (Rob Landley) Date: Sun, 30 Dec 2001 13:59:28 +0000 (GMT) Cc: esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011230134125.VUHO28486.femail48.sdc1.sfba.home.com@there> from "Rob Landley" at Dec 30, 2001 12:39:43 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > > Just a minor point, but what about non-PCI/ISA ide? > > The CML1 rules seem to imply that this set is empty. > > There are, apparently, paralell port IDE devices. > > I've never seen one, but we've got drivers for them. See PARIDE and > paride_devices. There are IDE drives on just about every conceivable bus or interface. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 08:59:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 08:59:24 -0500 Received: from ns.caldera.de ([212.34.180.1]:58043 "EHLO ns.caldera.de") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 08:59:12 -0500 Date: Sun, 30 Dec 2001 14:58:31 +0100 From: Christoph Hellwig To: "Eric S. Raymond" , Alexander Viro , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011230145831.A30561@caldera.de> Mail-Followup-To: Christoph Hellwig , "Eric S. Raymond" , Alexander Viro , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011228141211.B15338@thyrsus.com> <20011228153902.B17774@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20011228153902.B17774@thyrsus.com>; from esr@thyrsus.com on Fri, Dec 28, 2001 at 03:39:02PM -0500 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 03:39:02PM -0500, Eric S. Raymond wrote: > It may be that the reason our experiences have been different is because we > focus on different target languages. But I think my experience is an > existence proof that there *is* demand for localization and that meeting > it can have useful results. Is your native language something different thæn english or Al's? Localization for technical messages sucks. badly. Just take a look at a european computer magazine, you will find lots of english words in the text because there is no german/frensh/whatever one. Trying to use different grammar doesn't help the understanding. Christoph -- Of course it doesn't work. We've performed a software upgrade. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 09:36:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 09:36:40 -0500 Received: from mail.mbi-berlin.de ([194.95.11.12]:50667 "EHLO mail.mbi-berlin.de") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 09:36:32 -0500 Date: Sun, 30 Dec 2001 15:37:29 +0100 From: Viktor Rosenfeld To: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system Message-ID: <20011230153729.A1378@bart> Mail-Followup-To: linux-kernel@vger.kernel.org In-Reply-To: <20011230043458.E2434@bart> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-GPG-Key: http://www.informatik.hu-berlin.de/~rosenfel/public_key.asc Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dave Jones wrote: > Things have changed dramatically since 1995. > In particular, distros got a lot friendlier to install, and customise. > If theres a valid reason for Aunt Tillie to rebuild her kernel, it means > her distro of choice is doing something wrong. Yes, Aunt Tillie should not have to build a new kernel. But 13-year-old Joe Geek might want to try that out, as well as your next door neighbor, who just might be an IT guy, trying to switch his department to Linux. > Dumbing down the learning curve doesn't necessary make things easier > for people to learn. Reluctance to read documentation for eg is something > that will plague us no matter how simple we make it to build kernels. I'm not talking about dumbing down the learning curve. This is about tools that do the job they're supposed to do in a correct way, without having to rely on some inside voodoo magic, that is poorly documented, if at all. Cheers, Viktor --=20 Viktor Rosenfeld WWW: http://www.informatik.hu-berlin.de/~rosenfel/ --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8LyapkWI06CMxQ0ARAhavAJ9M88tnV1d2yVWICtRwA0Mm3VSsiQCfWVR6 CjXJ3Nlxo8kqMa4oSVIBWwE= =3hvj -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 12:14:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 12:14:39 -0500 Received: from t2.redhat.com ([199.183.24.243]:240 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 12:14:38 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: David Woodhouse X-Accept-Language: en_GB In-Reply-To: <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> In-Reply-To: <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> <20011228141211.B15338@thyrsus.com> <20011228173151.B20254@thyrsus.com> To: Tom Rini Cc: "Eric S. Raymond" , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Dec 2001 17:14:22 +0000 Message-ID: <28305.1009732462@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org trini@kernel.crashing.org said: > > unless (ISA or PCI) suppress dependent IDE > Just a minor point, but what about non-PCI/ISA ide? Eric is merely representing the _existing_ rules. Changing the behaviour can come later - that shouldn't be done at the same time as introducing CML2. -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 12:33:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 12:33:22 -0500 Received: from cpe-24-221-152-185.az.sprintbbd.net ([24.221.152.185]:57524 "EHLO opus.bloom.county") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 12:33:19 -0500 Date: Sun, 30 Dec 2001 10:32:58 -0700 From: Tom Rini To: David Woodhouse Cc: "Eric S. Raymond" , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011230173258.GA28513@cpe-24-221-152-185.az.sprintbbd.net> In-Reply-To: <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> <20011228141211.B15338@thyrsus.com> <20011228173151.B20254@thyrsus.com> <28305.1009732462@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28305.1009732462@redhat.com> User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 30, 2001 at 05:14:22PM +0000, David Woodhouse wrote: > > trini@kernel.crashing.org said: > > > unless (ISA or PCI) suppress dependent IDE > > > Just a minor point, but what about non-PCI/ISA ide? > > Eric is merely representing the _existing_ rules. Changing the behaviour > can come later - that shouldn't be done at the same time as introducing CML2. Yes, but what I was getting at was that these constraints will change (either because they were incorrect or no longer aplicable). Either way, why not fix bugs now? (since there are non-PCI/ISA ide, which is why I kept that example to start with). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 12:45:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 12:45:22 -0500 Received: from www.deepbluesolutions.co.uk ([212.18.232.186]:33810 "EHLO caramon.arm.linux.org.uk") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 12:45:08 -0500 Date: Sun, 30 Dec 2001 17:44:37 +0000 From: Russell King To: David Woodhouse Cc: Tom Rini , "Eric S. Raymond" , Linus Torvalds , Legacy Fishtank , Dave Jones , "Eric S. Raymond" , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20011230174437.D9625@flint.arm.linux.org.uk> In-Reply-To: <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> <20011228141211.B15338@thyrsus.com> <20011228173151.B20254@thyrsus.com> <20011229212455.GB21928@cpe-24-221-152-185.az.sprintbbd.net> <28305.1009732462@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <28305.1009732462@redhat.com>; from dwmw2@infradead.org on Sun, Dec 30, 2001 at 05:14:22PM +0000 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 30, 2001 at 05:14:22PM +0000, David Woodhouse wrote: > trini@kernel.crashing.org said: > > > unless (ISA or PCI) suppress dependent IDE > > > Just a minor point, but what about non-PCI/ISA ide? > > Eric is merely representing the _existing_ rules. Changing the behaviour > can come later - that shouldn't be done at the same time as introducing CML2. Existing rules allow non-PCI/ISA IDE. Its a bug, not a change of behaviour. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 12:50:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 12:50:23 -0500 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:37134 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 12:50:11 -0500 Message-ID: <3C2F53D0.5942335F@mandrakesoft.com> Date: Sun, 30 Dec 2001 12:50:08 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: "Eric S. Raymond" , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system In-Reply-To: <20011228141211.B15338@thyrsus.com> <20011228153902.B17774@thyrsus.com> <20011230145831.A30561@caldera.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Christoph Hellwig wrote: > Localization for technical messages sucks. badly. > Just take a look at a european computer magazine, you will find lots of > english words in the text because there is no german/frensh/whatever > one. Trying to use different grammar doesn't help the understanding. Or take a look at a BSD or Linux Web page in one of the oriental languages... even it contains English quite often. Jeff -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 12:53:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 12:53:22 -0500 Received: from mailout03.sul.t-online.com ([194.25.134.81]:51610 "EHLO mailout03.sul.t-online.com") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 12:53:12 -0500 Date: 30 Dec 2001 13:42:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: viro@math.psu.edu cc: linux-kernel@vger.kernel.org Message-ID: <8FqGN-B1w-B@khms.westfalen.de> In-Reply-To: Subject: Re: [kbuild-devel] Re: State of the new config & build system X-Mailer: CrossPoint v3.12d.kh8 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? In-Reply-To: X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org alan@lxorguk.ukuu.org.uk (Alan Cox) wrote on 28.12.01 in : > > Frankly, I find it very amusing that advocates of i18n efforts tend to > > be either British or USAnians. Folks, get real - your languages are > > too close to show where the problems are. I can see how doing that > > gives you a warm fuzzy feeling, but could you please listen to those > > of us who have to deal with the resulting mess for real? > > The biggest advocates I see are from the Middle-East and Japan. We already > have people providing translations for Configure.help in several languages. Once upon a time, I installed the German version of the man pages. Shortly after that, I switched to doing "LANG= man ..." because of exactly the problem Al mentions. But just recently I have been considering going back to the German man pages, because the quality has become *MUCH* better. In fact, it's now obvious they are fairly close translations of the English ones. In short, i18n for Linux has been improving drastically at least in some areas. Of course that won't be the same for all target languages; German is probably one of the best-supported ones because Linux usage in Germany is so heavy. As for Configure.help specifically: it should be fairly easy to do a script which notices when the original of a translation has changed, and possibly either replaces it with the English version, or else does some other more or less intelligent thing about it. MfG Kai From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 15:16:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 15:15:54 -0500 Received: from hermes.fachschaften.tu-muenchen.de ([129.187.176.19]:46829 "HELO hermes.fachschaften.tu-muenchen.de") by vger.kernel.org with SMTP id convert rfc822-to-8bit; Sun, 30 Dec 2001 15:15:41 -0500 Date: Sun, 30 Dec 2001 21:15:33 +0100 (CET) From: Adrian Bunk X-X-Sender: bunk@mimas.fachschaften.tu-muenchen.de To: Christoph Hellwig cc: linux-kernel@vger.kernel.org, Subject: Re: [kbuild-devel] Re: State of the new config & build system In-Reply-To: <20011230145831.A30561@caldera.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 30 Dec 2001, Christoph Hellwig wrote: > On Fri, Dec 28, 2001 at 03:39:02PM -0500, Eric S. Raymond wrote: > > It may be that the reason our experiences have been different is because we > > focus on different target languages. But I think my experience is an > > existence proof that there *is* demand for localization and that meeting > > it can have useful results. > > Is your native language something different thæn english or Al's? > > Localization for technical messages sucks. badly. > Just take a look at a european computer magazine, you will find lots of > english words in the text because there is no german/frensh/whatever > one. Trying to use different grammar doesn't help the understanding. For some people it helps when the text is in e.g. German although the technical words are still English. The most important point I see is: If the tanslation works similar to gettext, IOW there's a seperate directory that contains the complete translations I can't see problem for the "normal" kernel hacker: You don't have to care about the translations but if someone wants to provide a translation to e.g. Esperanto he can always do so by adding a file with the translated texts. People like you and me who prefer the English version can always use it but other people who prefer the translated messages can use them instead. > Christoph cu Adrian From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 30 Dec 2001 15:53:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 30 Dec 2001 15:53:34 -0500 Received: from mail1.arcor-ip.de ([145.253.2.10]:33001 "EHLO mail1.arcor-ip.de") by vger.kernel.org with ESMTP id ; Sun, 30 Dec 2001 15:53:14 -0500 Message-ID: <3C2F7EAD.9060805@arcormail.de> Date: Sun, 30 Dec 2001 21:53:01 +0100 From: Hartmut Holz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: State of the new config & build system In-Reply-To: <20011228141211.B15338@thyrsus.com> <20011228153902.B17774@thyrsus.com> <20011230145831.A30561@caldera.de> <3C2F53D0.5942335F@mandrakesoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jeff Garzik wrote: > Christoph Hellwig wrote: > >>Localization for technical messages sucks. badly. >>Just take a look at a european computer magazine, you will find lots of >>english words in the text because there is no german/frensh/whatever >>one. Trying to use different grammar doesn't help the understanding. >> > > Or take a look at a BSD or Linux Web page in one of the oriental > languages... even it contains English quite often. > Best example is IBM. It's only possible to install the DB2 client in your native Language (may be German) on Windows. The manual's are in English. So, for example a trigger is a Auslöser - very strange. May be they should translate the SQL Language to. Would be a little bit easier and I can start with computing from scratch again. Another nice thing is Excel. You use German for the table and English for VB programing. For example: table: zeichen() == VB char(). On the other hand, the only population who dubbed/translate every movie/thing into German, are the German's. Most others (for example Scandinavia, Netherland) use the original Language (mostly English) with subtitles. Hartmut From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 31 Dec 2001 01:52:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 31 Dec 2001 01:52:06 -0500 Received: from megaela.fe.dis.titech.ac.jp ([131.112.171.110]:14852 "HELO megaela.srvf.org") by vger.kernel.org with SMTP id ; Mon, 31 Dec 2001 01:51:56 -0500 Date: Mon, 31 Dec 2001 15:50:29 +0900 Message-ID: From: GOTO Masanori To: Alan Cox Cc: viro@math.psu.edu (Alexander Viro), esr@thyrsus.com (Eric S. Raymond), torvalds@transmeta.com (Linus Torvalds), garzik@havoc.gtf.org (Legacy Fishtank), davej@suse.de (Dave Jones), esr@snark.thyrsus.com (Eric S. Raymond), marcelo@conectiva.com.br (Marcelo Tosatti), linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: In-Reply-To: User-Agent: Wanderlust/2.9.2 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Fri, 28 Dec 2001 23:20:01 +0000 (GMT), Alan Cox wrote: > > Frankly, I find it very amusing that advocates of i18n efforts tend to > > be either British or USAnians. Folks, get real - your languages are > > too close to show where the problems are. I can see how doing that > > gives you a warm fuzzy feeling, but could you please listen to those > > of us who have to deal with the resulting mess for real? > > The biggest advocates I see are from the Middle-East and Japan. We already > have people providing translations for Configure.help in several languages. Yes. We JF Project (Japan) is still keeping translating Configure.help into Japanese for the stable kernel version 2.0, 2.2, and 2.4. We have some interest in distributing our translated-Configure.help, but, such distribution needs so-high-precious technical translation. I think to leave quality control of Configure.help from developer is not good, we have to be so careful, and it's a big problem. In addition, I think we need a framework for keeping up to date with the latest Configure.help against translated Configure.help. Consistency between original Configure.help and translated-Configure.help must be kept. IMHO, for example, if CONFIG_FOO is changed between 2.4.16 and 2.4.17, then (translated-)CONFIG_FOO must show in original English, even if we have only 2.4.16-translated-CONFIG_FOO, and so on. -- gotom From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 31 Dec 2001 03:25:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 31 Dec 2001 03:25:45 -0500 Received: from megaela.fe.dis.titech.ac.jp ([131.112.171.110]:19204 "HELO megaela.srvf.org") by vger.kernel.org with SMTP id ; Mon, 31 Dec 2001 03:25:32 -0500 Date: Mon, 31 Dec 2001 17:24:11 +0900 Message-ID: From: GOTO Masanori To: kaih@khms.westfalen.de (Kai Henningsen) Cc: viro@math.psu.edu, linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: State of the new config & build system In-Reply-To: <8FqGN-B1w-B@khms.westfalen.de> In-Reply-To: <8FqGN-B1w-B@khms.westfalen.de> User-Agent: Wanderlust/2.9.2 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At 30 Dec 2001 13:42:00 +0200, Kai Henningsen wrote: > But just recently I have been considering going back to the German man > pages, because the quality has become *MUCH* better. In fact, it's now > obvious they are fairly close translations of the English ones. Well, I don't know the quality of German's, but I know German's have much of localized message :) However, imagine other languages. The quality control of localized translation can know only people who are ready for that language. I think it's the problem. > As for Configure.help specifically: it should be fairly easy to do a > script which notices when the original of a translation has changed, and > possibly either replaces it with the English version, or else does some > other more or less intelligent thing about it. Well, such a mechanism is also needed whenever if we have official translation system (like DDTS - Debian Description Translation System). -- gotom From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 31 Dec 2001 17:56:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 31 Dec 2001 17:55:59 -0500 Received: from garrincha.netbank.com.br ([200.203.199.88]:51986 "HELO netbank.com.br") by vger.kernel.org with SMTP id ; Mon, 31 Dec 2001 17:55:51 -0500 Date: Mon, 31 Dec 2001 20:55:52 -0200 From: Arnaldo Carvalho de Melo To: Horst von Brand Cc: Alan Cox , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011231205552.A17089@conectiva.com.br> Mail-Followup-To: Arnaldo Carvalho de Melo , Horst von Brand , Alan Cox , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <200112312251.fBVMpNws032221@sleipnir.valparaiso.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112312251.fBVMpNws032221@sleipnir.valparaiso.cl> User-Agent: Mutt/1.3.23i X-Url: http://advogato.org/person/acme Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Em Mon, Dec 31, 2001 at 07:51:23PM -0300, Horst von Brand escreveu: > Alan Cox said: > > Something like: > > > > find $TOPDIR -name "*.cf" -exec cat {} \; > Configure.help > > Make that: > > cat `find $TOPDIR -name "*.cf"` > Configure.help #;-) whatever is faster, do you have trustable benchmark numbers? ;) Yes, its a joke, have a nice 2002 all! - Arnaldo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 31 Dec 2001 17:52:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 31 Dec 2001 17:52:16 -0500 Received: from chac.inf.utfsm.cl ([200.1.19.54]:6918 "EHLO chac.inf.utfsm.cl") by vger.kernel.org with ESMTP id ; Mon, 31 Dec 2001 17:52:14 -0500 Message-Id: <200112312251.fBVMpNws032221@sleipnir.valparaiso.cl> To: Alan Cox cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 18:24:02 -0000." X-mailer: MH [Version 6.8.4] X-charset: ISO_8859-1 Date: Mon, 31 Dec 2001 19:51:23 -0300 From: Horst von Brand Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox said: > Something like: > > find $TOPDIR -name "*.cf" -exec cat {} \; > Configure.help Make that: cat `find $TOPDIR -name "*.cf"` > Configure.help #;-) -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Vin~a del Mar, Chile +56 32 672616 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 31 Dec 2001 18:32:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 31 Dec 2001 18:32:48 -0500 Received: from chac.inf.utfsm.cl ([200.1.19.54]:11782 "EHLO chac.inf.utfsm.cl") by vger.kernel.org with ESMTP id ; Mon, 31 Dec 2001 18:32:44 -0500 Message-Id: <200112312332.fBVNWKBG032643@sleipnir.valparaiso.cl> To: esr@thyrsus.com Cc: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 28 Dec 2001 15:39:02 CDT." <20011228153902.B17774@thyrsus.com> X-mailer: MH [Version 6.8.4] X-charset: ISO_8859-1 Date: Mon, 31 Dec 2001 20:32:19 -0300 From: Horst von Brand Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Eric S. Raymond" said: [...] > Which is why there are organized translation groups that do periodic > translation updates for software that has registered with them. This > doesn't eliminate the problem, but it can keep it within manageable bounds > that make having localizations better than not. I deal with this regularly > with respect to fetchmail. Translations do suck: In Spanish, there are several "dialects" of computer terms in common use. Get a book written in one of those, and try to make sense on texts using another convention. Or just try to read the original English documentation... To do a good translation you need (a) good understanding of the source language (enough to be able to work around bugs in the original rendering), (b) extensive knowledge of the target language, (c) knowledge of the task at hand. Getting all three together is hard. Besides, stuff like comments and help messages does suffer bitrot very much as it doesn't (much) affect functioning, translations are much worse as they have even less exposure (== even less selective pressure to stay right). [...] > No, not always. I read French, Italian, and Spanish; I can puzzle out > technical prose in a couple of other languages. I can read > fetchmail's .po files and *see* that they don't suck. You _know_ what the English text says. To be able to make sense of a text when you have a rather clear idea what it says is a lot easier than trying to puzzle it out when you have no clue. Not to say that the files in fetchmail aren OK (I looked at them myself (German, Spanish) a while back and found little to patch). -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Vin~a del Mar, Chile +56 32 672616 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 31 Dec 2001 20:22:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 31 Dec 2001 20:21:57 -0500 Received: from wire.cadcamlab.org ([156.26.20.181]:47110 "EHLO wire.cadcamlab.org") by vger.kernel.org with ESMTP id ; Mon, 31 Dec 2001 20:21:50 -0500 Date: Mon, 31 Dec 2001 19:21:19 -0600 To: Arnaldo Carvalho de Melo , Horst von Brand , Alan Cox , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20020101012119.GA1303@cadcamlab.org> In-Reply-To: <200112312251.fBVMpNws032221@sleipnir.valparaiso.cl> <20011231205552.A17089@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011231205552.A17089@conectiva.com.br> User-Agent: Mutt/1.3.24i From: Peter Samuelson Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org [Alan Cox] > > > find $TOPDIR -name "*.cf" -exec cat {} \; > Configure.help [Horst von Brand] > > cat `find $TOPDIR -name "*.cf"` > Configure.help #;-) [Arnaldo Carvalho de Melo] > whatever is faster, do you have trustable benchmark numbers? ;) Fewer forks vs. increased parallelism ... depends on the nature of your bottlenecks, I guess, and cold vs. hot cache. Or you could have it both ways: find $TOPDIR -name \*.cf | xargs -n10 cat > Configure.help ...where 10 is tuned by benchmarking. (: > Yes, its a joke, have a nice 2002 all! Yeah, same from me.. Peter From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 31 Dec 2001 23:04:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 31 Dec 2001 23:04:24 -0500 Received: from barbados.bluemug.com ([63.195.182.101]:27911 "EHLO barbados.bluemug.com") by vger.kernel.org with ESMTP id ; Mon, 31 Dec 2001 23:04:16 -0500 Date: Mon, 31 Dec 2001 20:03:59 -0800 To: Keith Owens Cc: Larry McVoy , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20011231200359.A22497@bluemug.com> Mail-Followup-To: Keith Owens , Larry McVoy , "Eric S. Raymond" , Dave Jones , "Eric S. Raymond" , Linus Torvalds , Marcelo Tosatti , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20011227174723.V25698@work.bitmover.com> <19047.1009504678@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19047.1009504678@ocs3.intra.ocs.com.au> X-PGP-ID: 5C09BB33 X-PGP-Fingerprint: C518 67A5 F5C5 C784 A196 B480 5C97 3BBD 5C09 BB33 From: Mike Touloumtzis Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2001 at 12:57:58PM +1100, Keith Owens wrote: > > Unlike the broken make dep, kbuild 2.5 extracts accurate dependencies > by using the -MD option of cpp and post processing the cpp list. The > post processing code is slow because the current design requires every > compile to read a complete list of all the files, giving O(n^2) > effects. Mark 2 of the core code will use a shared database with > concurrent update so post processing is limited to looking up just the > required files, instead of reading the complete list every time. Why not use '$(GCC) -c -Wp,-MD,foo.d foo.c' to generate the dependencies as a side effect of the regular compile step? This enables you to skip the initial dependency preprocessing step entirely, and could lead to a speedup over even the current fastdep system. You still have to massage the dependencies but you can do it based on the side-effect dependency output of the _previous_ build, to whatever degree that output exists. This strategy allows for lazy dependency generation in those cases in which the dependencies need not be known--for example, if floppy.o doesn't exist, you know it needs to be built no matter which header files floppy.c may include. This breaks down in some cases (as when a .c file depends on a generated .h file) but those breakdown cases can be explicitly identified, and a full dependency tree be generated for them in an eager, rather than a lazy, fashion. It seems like it's worth it if it leads to a near 100% speedup over the current kbuild 2.5. The "build whole clean tree" case is a common one even among kernel developers, e.g. for compile-testing patches before resending them. miket From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 31 Dec 2001 23:34:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 31 Dec 2001 23:34:13 -0500 Received: from chac.inf.utfsm.cl ([200.1.19.54]:29446 "EHLO chac.inf.utfsm.cl") by vger.kernel.org with ESMTP id ; Mon, 31 Dec 2001 23:34:10 -0500 Message-Id: <200201010429.g014TO9j002744@sleipnir.valparaiso.cl> To: Christoph Hellwig cc: "Eric S. Raymond" , Alexander Viro , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system In-Reply-To: Your message of "Sun, 30 Dec 2001 14:58:31 BST." <20011230145831.A30561@caldera.de> X-mailer: MH [Version 6.8.4] X-charset: ISO_8859-1 Date: Tue, 01 Jan 2002 01:29:24 -0300 From: Horst von Brand Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Christoph Hellwig said: > On Fri, Dec 28, 2001 at 03:39:02PM -0500, Eric S. Raymond wrote: > > It may be that the reason our experiences have been different is > > because we focus on different target languages. But I think my > > experience is an existence proof that there *is* demand for > > localization and that meeting it can have useful results. > Is your native language something different thæn english or Al's? > > Localization for technical messages sucks. badly. > Just take a look at a european computer magazine, you will find lots of > english words in the text because there is no german/frensh/whatever > one. Trying to use different grammar doesn't help the understanding. It is even worse when they try to "translate" the terms. In Spanish, the official language calls a computer "ordenador" (sorting device), and a file "fichero" (filing cabinet). It doesn't help in the least at understanding the _English_ documentation/source/... Add to it that here in South America they usually take over the English terms, using "computador" (computing device) and "archivo" (file). So it can even make it hard to understand the technical literature in your own language... My standard advise is to learn English, if nothing else for uniformity's sake. You'll need it anyway before long in anything related to computing. And it is quite useful in other areas... -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Vin~a del Mar, Chile +56 32 672616 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 1 Jan 2002 03:27:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 1 Jan 2002 03:27:27 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:31504 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Tue, 1 Jan 2002 03:27:14 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Mike Touloumtzis Cc: Larry McVoy , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system In-Reply-To: Your message of "Mon, 31 Dec 2001 20:03:59 -0800." <20011231200359.A22497@bluemug.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Jan 2002 19:26:59 +1100 Message-ID: <3680.1009873619@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 31 Dec 2001 20:03:59 -0800, Mike Touloumtzis wrote: >On Fri, Dec 28, 2001 at 12:57:58PM +1100, Keith Owens wrote: >> >> Unlike the broken make dep, kbuild 2.5 extracts accurate dependencies >> by using the -MD option of cpp and post processing the cpp list. The >> post processing code is slow because the current design requires every >> compile to read a complete list of all the files, giving O(n^2) >> effects. Mark 2 of the core code will use a shared database with >> concurrent update so post processing is limited to looking up just the >> required files, instead of reading the complete list every time. > >Why not use '$(GCC) -c -Wp,-MD,foo.d foo.c' to generate the dependencies >as a side effect of the regular compile step? This enables you to skip >the initial dependency preprocessing step entirely, and could lead to a >speedup over even the current fastdep system. You still have to massage >the dependencies but you can do it based on the side-effect dependency >output of the _previous_ build, to whatever degree that output exists. That is exactly what kbuild 2.5 does. The slowdown occurs when massaging the -MD dependencies from absolute names to relative path names. To support separate source and object trees, renaming of trees, different names in local and NFS mode etc., the massage code needs a list of where all the files are before it can convert the absolute dependencies produced by gcc. Reading and indexing that file for every compile is _slow_. Larry McVoy has sent me the source code to an mmapped database (from bitkeeper). Using a shared mmapped database should speed the process up considerably. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 1 Jan 2002 03:56:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 1 Jan 2002 03:55:49 -0500 Received: from wire.cadcamlab.org ([156.26.20.181]:43015 "EHLO wire.cadcamlab.org") by vger.kernel.org with ESMTP id ; Tue, 1 Jan 2002 03:55:45 -0500 Date: Tue, 1 Jan 2002 02:55:40 -0600 To: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: State of the new config & build system Message-ID: <20020101085540.GB1303@cadcamlab.org> In-Reply-To: <20011227174723.V25698@work.bitmover.com> <19047.1009504678@ocs3.intra.ocs.com.au> <20011231200359.A22497@bluemug.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011231200359.A22497@bluemug.com> User-Agent: Mutt/1.3.24i From: Peter Samuelson Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org [Mike Touloumtzis] > Why not use '$(GCC) -c -Wp,-MD,foo.d foo.c' to generate the > dependencies as a side effect of the regular compile step? As Keith said, kbuild 2.5 *does* use 'gcc -MD' - although the *current* system does not. Linus has said that he doesn't like -MD, and he has a point: it only extracts dependencies for your *current* compile, which means they have to be rebuilt if you change CONFIG options. However, those CONFIG options would cause rebuilding of the file *anyway*, and -MD is almost free since the preprocessor already has to read the files in question, so I'm not convinced that it's a big deal. > The "build whole clean tree" case is a common one even among kernel > developers, e.g. for compile-testing patches before resending them. One of the main points of kbuild 2.5 is that, unlike the current system, it tracks dependencies perfectly. Thus you should almost never have to run 'make clean' before test compiling something - unless you need to see non-fatal compile warnings. It may take some time to get used to the soon-to-be new reality of "ok, so I just applied eight kernel patches from three different places but I know I don't need to bother with 'make clean' because the dependency system is just *that good*." Peter From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 15:05:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 15:05:19 -0500 Received: from smtp1.vol.cz ([195.250.128.73]:17676 "EHLO smtp1.vol.cz") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 15:05:08 -0500 Date: Thu, 3 Jan 2002 10:46:06 +0000 From: Pavel Machek To: Daniel Phillips Cc: Andrew Morton , Legacy Fishtank , Keith Owens , Mike Castle , linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system Message-ID: <20020103104605.A37@toy.ucw.cz> In-Reply-To: <20011229042139.GC14067@thune.mrc-home.com> <20011229024143.A11696@havoc.gtf.org> <3C2D7B2B.C1362850@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from phillips@bonn-fries.net on Sat, Dec 29, 2001 at 10:40:33AM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi! > > > On Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens wrote: > > > > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more > > > > flexible and accurate than 2.4, including features that lots of people > > > > want, like separate source and object trees. > > > > > > I don't see the masses, or, well, anybody on lkml, clamoring for this. > > > > Clamour. > > Clamour. Clamour. Being able to cp -a then build without full rebuild is good. Also make dep takes *long* and and bad things happen when you think it was not needed ;-). Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 15:29:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 15:29:25 -0500 Received: from ns.suse.de ([213.95.15.193]:37384 "HELO Cantor.suse.de") by vger.kernel.org with SMTP id ; Thu, 3 Jan 2002 15:29:10 -0500 Date: Thu, 3 Jan 2002 21:29:09 +0100 (CET) From: Dave Jones To: Pavel Machek Cc: Daniel Phillips , Andrew Morton , Legacy Fishtank , Keith Owens , Mike Castle , Subject: Re: State of the new config & build system In-Reply-To: <20020103104605.A37@toy.ucw.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Jan 2002, Pavel Machek wrote: > Being able to cp -a then build without full rebuild is good. Also make dep > takes *long* and and bad things happen when you think it was not needed ;-). And being able to NFS share 1 kernel tree, and be able to do parallel builds on multiple boxes without having to wait until 1 is finished. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 15:35:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 15:35:37 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:7875 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 15:35:23 -0500 Date: Thu, 3 Jan 2002 15:35:19 -0500 (EST) From: Alexander Viro To: Dave Jones cc: Pavel Machek , Daniel Phillips , Andrew Morton , Legacy Fishtank , Keith Owens , Mike Castle , linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Jan 2002, Dave Jones wrote: > On Thu, 3 Jan 2002, Pavel Machek wrote: > > > Being able to cp -a then build without full rebuild is good. Also make dep > > takes *long* and and bad things happen when you think it was not needed ;-). > > And being able to NFS share 1 kernel tree, and be able to do parallel > builds on multiple boxes without having to wait until 1 is finished. Sigh... As soon as we get to prototype change in getattr()/setattr()/permission() - we get CoW fs. I.e. equivalent of *BSD unionfs. I hope to get around to that stuff around 2.5.4 or so. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 15:47:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 15:47:17 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:37136 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Thu, 3 Jan 2002 15:47:04 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alexander Viro Cc: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: Your message of "Thu, 03 Jan 2002 15:35:19 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jan 2002 07:46:49 +1100 Message-ID: <20733.1010090809@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Jan 2002 15:35:19 -0500 (EST), Alexander Viro wrote: >On Thu, 3 Jan 2002, Dave Jones wrote: >> And being able to NFS share 1 kernel tree, and be able to do parallel >> builds on multiple boxes without having to wait until 1 is finished. > > Sigh... As soon as we get to prototype change in >getattr()/setattr()/permission() - we get CoW fs. I.e. equivalent of >*BSD unionfs. I hope to get around to that stuff around 2.5.4 or so. Unionfs and cow fs will be nice but kernel build will not use it. Users can build a Linux kernel on other operating systems, including Solaris, Irix, Cygwin etc. kbuild requires a Posix compliant fs and GNU tools, but it must not use additional fs features that only exist on Linux or only on specific versions of Linux. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 16:31:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 16:31:15 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:30620 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 16:31:00 -0500 Date: Thu, 3 Jan 2002 16:30:55 -0500 (EST) From: Alexander Viro To: Keith Owens cc: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: <20733.1010090809@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Jan 2002, Keith Owens wrote: > On Thu, 3 Jan 2002 15:35:19 -0500 (EST), > Alexander Viro wrote: > >On Thu, 3 Jan 2002, Dave Jones wrote: > >> And being able to NFS share 1 kernel tree, and be able to do parallel > >> builds on multiple boxes without having to wait until 1 is finished. > > > > Sigh... As soon as we get to prototype change in > >getattr()/setattr()/permission() - we get CoW fs. I.e. equivalent of > >*BSD unionfs. I hope to get around to that stuff around 2.5.4 or so. > > Unionfs and cow fs will be nice but kernel build will not use it. > Users can build a Linux kernel on other operating systems, including > Solaris, Irix, Cygwin etc. kbuild requires a Posix compliant fs and > GNU tools, but it must not use additional fs features that only exist > on Linux or only on specific versions of Linux. kernel build doesn't have to use it - if I mount a writable layer atop of the clean tree and build in the resulting tree, build system doesn't need to have any idea of that fact. That's the point - you are emulating the thing that is generally useful and belongs to different layer - namely, the kernel. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 16:51:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 16:51:21 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:53776 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Thu, 3 Jan 2002 16:51:06 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alexander Viro Cc: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: Your message of "Thu, 03 Jan 2002 16:30:55 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jan 2002 08:50:52 +1100 Message-ID: <21246.1010094652@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Jan 2002 16:30:55 -0500 (EST), Alexander Viro wrote: > kernel build doesn't have to use it - if I mount a writable layer >atop of the clean tree and build in the resulting tree, build system >doesn't need to have any idea of that fact. I have one big problem with unionfs and make, it cannot handle this scenario. * Mount COW layer over clean tree. * Edit a file, writing to the COW layer. * Build the kernel. * Decide that you don't want the change, delete the COW version, exposing the original version of the file, timestamp goes backwards. * Build the kernel. * make sees source timestamp < object timestamp and does not rebuild, the kernel source and object do not match. Obviously this is a design flaw in make, using only timestamps has been shown to be unreliable. As long as people use the standard make program, they will have problems with union filesystems. The problem is not restricted to unionfs, NFS timestamp skew also affects make, as well as checking out code from source repositories when the timestamp goes backwards. >That's the point - you are >emulating the thing that is generally useful and belongs to different >layer - namely, the kernel. I agree that unionfs is useful but it is not the panacea for kbuild that you think it is. The kbuild wrapper around make takes care of the timestamp problems as well as handling separate source and object trees, IOW it does unionfs plus a lot more work. If make did not rely on timestamps I would have been pushing for unionfs a long time ago, but as long as we are stuck with make's design, unionfs is not a fix. I thought about replacing make entirely with another tool like Scons but decided that none of the other tools on their own could cope with the peculiarities of the kernel build nor were they stable enough yet. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 17:13:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 17:12:52 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:478 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 17:11:39 -0500 Date: Thu, 3 Jan 2002 17:11:37 -0500 (EST) From: Alexander Viro To: Keith Owens cc: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: <21246.1010094652@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Jan 2002, Keith Owens wrote: > * Mount COW layer over clean tree. > * Edit a file, writing to the COW layer. > * Build the kernel. > * Decide that you don't want the change, delete the COW version, > exposing the original version of the file, timestamp goes backwards. ITYM "creating a whiteout entry". unlink() on unionfs doesn't expose the underlying object. It looks so: * each directory in covering layer has a flag (is_transparent) * all children of non-transparent directory are non-transparent * lookup in non-transparent directory is a usual lookup in covering layer. * lookup in transparent directory lookup in covering layer if found an object -> return it else if found whiteout -> no entry else do lookup in covered if not found -> no entry else if found is a directory create a directory in covering mark it transparent return new directory else -> return what we found * mkdir creates non-transparent directories * unlink and rmdir leave whiteout entry * attempt to modify file copies it into covering and modifies that copy. That gives you real copy-on-write semantics - when you remove object it stays removed; rm -rf foo && mkdir foo gives you an empty directory, etc. rename() support is messy - especially when it comes to renaming directories (if it was transparent you need to copy the entire subtree to covering layer). Whiteouts are usually represented as directory entries with no inode and type of entry being DT_WHT (14). Adding support of these beasts into ext2 is ~ 10 lines of patch. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 17:45:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 17:45:12 -0500 Received: from zok.SGI.COM ([204.94.215.101]:59554 "EHLO zok.sgi.com") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 17:45:00 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Alexander Viro Cc: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: Your message of "Thu, 03 Jan 2002 17:11:37 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jan 2002 09:44:49 +1100 Message-ID: <22327.1010097889@kao2.melbourne.sgi.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Jan 2002 17:11:37 -0500 (EST), Alexander Viro wrote: >On Fri, 4 Jan 2002, Keith Owens wrote: > >> * Mount COW layer over clean tree. >> * Edit a file, writing to the COW layer. >> * Build the kernel. >> * Decide that you don't want the change, delete the COW version, >> exposing the original version of the file, timestamp goes backwards. > >ITYM "creating a whiteout entry". unlink() on unionfs doesn't expose >the underlying object. It does in kbuild 2.5. You have a pristine source tree, start a development layer, edit files, build a kernel, decide your edit was wrong, delete the updated version, expose the original and kbuild 2.5 still gets it right. IMHO that model better fits kernel development. The whiteout model makes it more difficult to revert to the standard kernel, you have to copy the original code to your writeable layer to back out changes. To satisfy the broken make design, you cannot copy with timestamp. When the base layer changes to a new release, the COW version does not get upgraded, even though it is supposed to be identical to the base layer. Again, I am not disagreeing with unionfs, it has its uses. kbuild using make and relying solely on timestamps to detect changes is not one of them. Especially when kbuild has to run on other operating systems. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 21:00:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 21:00:08 -0500 Received: from smtp-ham-2.netsurf.de ([194.195.64.98]:60102 "EHLO smtp-ham-2.netsurf.de") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 20:59:57 -0500 Date: Fri, 4 Jan 2002 02:49:38 +0100 From: Andreas Bombe To: Keith Owens Cc: Alexander Viro , linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system Message-ID: <20020104014938.GA3474@storm.local> Mail-Followup-To: Keith Owens , Alexander Viro , linux-kernel@vger.kernel.org In-Reply-To: <21246.1010094652@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21246.1010094652@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 04, 2002 at 08:50:52AM +1100, Keith Owens wrote: > On Thu, 3 Jan 2002 16:30:55 -0500 (EST), > Alexander Viro wrote: > > kernel build doesn't have to use it - if I mount a writable layer > >atop of the clean tree and build in the resulting tree, build system > >doesn't need to have any idea of that fact. > > I have one big problem with unionfs and make, it cannot handle this > scenario. > > * Mount COW layer over clean tree. > * Edit a file, writing to the COW layer. > * Build the kernel. > * Decide that you don't want the change, delete the COW version, > exposing the original version of the file, timestamp goes backwards. > * Build the kernel. > * make sees source timestamp < object timestamp and does not rebuild, > the kernel source and object do not match. Isn't that a thinko in there? The build using the edited file would happen in the same layer as that file or in another one on top. If it's the same, the build would be deleted with the change. If it's in another one on top you'd be removing a layer in the middle. I don't know if that should be possible without user intervention (unmount build and change layers, delete change layer, mount build layer over source). There is something said about Unix and ropes, I remember. Then again I don't know the unionfs idea in these details, so I may be wrong. Unionfs as I understand it would be great for editing/patching and building. Build a kernel in the pristine sources, mount a COW layer over it where you patch/edit, build there. In the ideal case the COW layer would only build the changed file(s) and link vmlinux with all the other objects from the pristine build. This wouldn't affect the pristine build itself at all, no make problems there when you remove the COW build&change layer. -- Andreas Bombe DSA key 0x04880A44 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 21:31:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 21:31:32 -0500 Received: from zok.SGI.COM ([204.94.215.101]:38068 "EHLO zok.sgi.com") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 21:31:21 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Andreas Bombe Cc: Alexander Viro , linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system In-Reply-To: Your message of "Fri, 04 Jan 2002 02:49:38 BST." <20020104014938.GA3474@storm.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jan 2002 13:31:08 +1100 Message-ID: <24687.1010111468@kao2.melbourne.sgi.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Jan 2002 02:49:38 +0100, Andreas Bombe wrote: >Unionfs as I understand it would be great for editing/patching and >building. Build a kernel in the pristine sources, mount a COW layer >over it where you patch/edit, build there. In the ideal case the COW >layer would only build the changed file(s) and link vmlinux with all the >other objects from the pristine build. This wouldn't affect the >pristine build itself at all, no make problems there when you remove the >COW build&change layer. You are talking about removing an entire layer, I am talking about removing individual files when you decide the edit failed. Removing the entire layer works, as long as all changes are always made to the top layer. Removing individual files gets into timestamp problems. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 16:44:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 16:44:23 -0500 Received: from smtp-ham-2.netsurf.de ([194.195.64.98]:62876 "EHLO smtp-ham-2.netsurf.de") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 16:44:14 -0500 Date: Fri, 4 Jan 2002 22:40:07 +0100 From: Andreas Bombe To: Keith Owens Cc: linux-kernel@vger.kernel.org Subject: Re: State of the new config & build system Message-ID: <20020104214007.GA11072@storm.local> Mail-Followup-To: Keith Owens , linux-kernel@vger.kernel.org In-Reply-To: <20020104014938.GA3474@storm.local> <24687.1010111468@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24687.1010111468@kao2.melbourne.sgi.com> User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 04, 2002 at 01:31:08PM +1100, Keith Owens wrote: > On Fri, 4 Jan 2002 02:49:38 +0100, > Andreas Bombe wrote: > >Unionfs as I understand it would be great for editing/patching and > >building. Build a kernel in the pristine sources, mount a COW layer > >over it where you patch/edit, build there. In the ideal case the COW > >layer would only build the changed file(s) and link vmlinux with all the > >other objects from the pristine build. This wouldn't affect the > >pristine build itself at all, no make problems there when you remove the > >COW build&change layer. > > You are talking about removing an entire layer, I am talking about > removing individual files when you decide the edit failed. Removing > the entire layer works, as long as all changes are always made to the > top layer. Removing individual files gets into timestamp problems. Duh, you are right. That can't be solved cleanly. -- Andreas Bombe DSA key 0x04880A44 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 6 Jan 2002 11:16:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 6 Jan 2002 11:16:16 -0500 Received: from prahad-2-15.dialup.vol.cz ([212.27.197.123]:260 "EHLO albireo.ucw.cz") by vger.kernel.org with ESMTP id ; Sun, 6 Jan 2002 11:16:11 -0500 Date: Sun, 6 Jan 2002 09:55:49 +0100 From: Martin Mares To: Keith Owens Cc: Mike Touloumtzis , Larry McVoy , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20020106095549.A664@ucw.cz> In-Reply-To: <20011231200359.A22497@bluemug.com> <3680.1009873619@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3680.1009873619@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.20i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi Keith, > That is exactly what kbuild 2.5 does. The slowdown occurs when > massaging the -MD dependencies from absolute names to relative path > names. To support separate source and object trees, renaming of trees, > different names in local and NFS mode etc., the massage code needs a > list of where all the files are before it can convert the absolute > dependencies produced by gcc. Reading and indexing that file for every > compile is _slow_. I didn't follow the thread from the very beginning nor did I study your makefiles carefully, because I don't have much time for kernel hacking these days, but maybe I won't miss the pond :) Is there any reason for processing all the files for each compile instead of merging them to a single file once at the start of the make? I use it in one of my projects, there is the relevant part of the Makefile: # Black magic with dependencies. It would be more correct to make "depend.new" # a prerequisite for "depend", but "depend.new" often has the same timestamp # as "depend" which would confuse make a lot and either force remaking anyway # or (as in current versions of GNU make) erroneously skipping the remaking. -include depend depend: force if [ -s depend.new ] ; then build/mergedeps depend depend.new ; >depend.new ; fi force: # Implicit rules obj/%.o: %.c DEPENDENCIES_OUTPUT="depend.new $@" $(CC) $(CFLAGS) -c -o $@ $< The DEPENDENCIES_OUTPUT mode is much more convenient than gcc -Mx as it avoids scattering the relevant information over many files. The mergedeps script is a simple Perl script which takes care of merging the dependencies gathered during the previous run of make to the depend file for the next run. It can do a lot of fixups and translations, here is a trivial example: #!/usr/bin/perl @ARGV == 2 or die "Usage: mergedeps "; foreach $a (@ARGV) { open F, "$a" or next; $t = ""; while () { $t .= $_; if (! /\\$/) { ($t =~ /^(.*):/) || die "Parse error at $t"; $rules{$1} = $t; $t = ""; } } close F; } open(F,">" . $ARGV[0]) || die "Unable to write output file"; foreach $a (sort keys %rules) { print F $rules{$a}; } close F; Have a nice fortnight -- Martin `MJ' Mares http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Light-year? One-third less calories than a regular year. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 6 Jan 2002 17:21:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 6 Jan 2002 17:20:26 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:50449 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Sun, 6 Jan 2002 17:20:14 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Martin Mares Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system In-Reply-To: Your message of "Sun, 06 Jan 2002 09:55:49 BST." <20020106095549.A664@ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Jan 2002 09:19:59 +1100 Message-ID: <23415.1010355599@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 6 Jan 2002 09:55:49 +0100, Martin Mares wrote: >Is there any reason for processing all the files for each compile >instead of merging them to a single file once at the start of the make? The main reason is to convert absolute dependency names to $(xxx) followed by a relative name, where xxx is one of the KBUILD_OBJTREE or KBUILD_SRCTREE_nnn variables. This conversion allows users to rename their source and object trees and to compile on one machine and install on another over NFS without being bitten by absolute dependencies. I really need to do that conversion using the current values of the kbuild variables, the variables might have changed on the next make. My new design for module symbol versions requires that the version data be stored immediately after the compile. That also requires processing after each compile using the current environment. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 9 Jan 2002 12:19:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 9 Jan 2002 12:18:23 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.31.123]:6920 "EHLO atrey.karlin.mff.cuni.cz") by vger.kernel.org with ESMTP id ; Wed, 9 Jan 2002 12:16:46 -0500 Date: Wed, 9 Jan 2002 18:16:35 +0100 From: Martin Mares To: Keith Owens Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: State of the new config & build system Message-ID: <20020109171635.GQ4019@atrey.karlin.mff.cuni.cz> In-Reply-To: <20020106095549.A664@ucw.cz> <23415.1010355599@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23415.1010355599@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi Keith, > The main reason is to convert absolute dependency names to $(xxx) > followed by a relative name, where xxx is one of the KBUILD_OBJTREE or > KBUILD_SRCTREE_nnn variables. This conversion allows users to rename > their source and object trees and to compile on one machine and install > on another over NFS without being bitten by absolute dependencies. I > really need to do that conversion using the current values of the > kbuild variables, the variables might have changed on the next make. Yes, I understand, but this could be done as well at the start of the make run, couldn't it? > My new design for module symbol versions requires that the version data > be stored immediately after the compile. That also requires processing > after each compile using the current environment. This sounds worse ... damned modversions, I still think it was one of the biggest mistakes in Linux history and an one which will be probably very hard to get rid of. Anyway, why do you need to process it immediately? Have a nice fortnight -- Martin `MJ' Mares http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Minimalist definition of maximalism: `more!'.