From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by dsl2.external.hp.com (Postfix) with ESMTP id 64258482A for ; Thu, 19 Apr 2001 20:36:40 -0600 (MDT) Date: Thu, 19 Apr 2001 20:36:39 -0600 To: esr@thyrsus.com Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Message-ID: <20010419203639.H4217@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: willy@ldl.fc.hp.com (Matthew Wilcox) Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote: > Remove dead CONFIG_BINFMT_JAVA symbol. Please don't do this, it just makes merging our patches with Linus harder. This has already been done in our tree since Feb 1. In fact, please don't touch anything in the tree which is PA specific; we have a large arch update pending. http://puffin.external.hp.com/cvs/linux/arch/parisc/config.in?log=y shows the current state of our config.in, if you're curious. If you have any changes you want to make, don't hesitate to coordinate with us by mailing parisc-linux@parisc-linux.org. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id 1CF7D482A for ; Thu, 19 Apr 2001 21:00:27 -0600 (MDT) Date: Thu, 19 Apr 2001 23:00:09 -0400 From: "Eric S. Raymond" To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Message-ID: <20010419230009.A32500@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010419203639.H4217@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010419203639.H4217@zumpano.fc.hp.com>; from willy@ldl.fc.hp.com on Thu, Apr 19, 2001 at 08:36:39PM -0600 Sender: esr@snark.thyrsus.com Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: Matthew Wilcox : > On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote: > > Remove dead CONFIG_BINFMT_JAVA symbol. > > Please don't do this, it just makes merging our patches with Linus harder. Bother. I've now heard "don't touch that tree!" from you and the ARM folks. I'm trying to be a good neighbor, here, but there is some cleanup I want to do that crosses port boundaries. (None of this is CML2, BTW; I'm now addressing problems that are common to CML1 as well.) What is the right procedure for doing changes like this? Is "don't touch that tree" a permanent condition, or am I going to get a chance to clean up the global CONFIG_ namespace after your next merge-down? Could I ask you to audit your tree and change the prefix on any CONFIG_ symbols that are private over there? This would make life easier for my auditing tools (kxref and Stephen Cole's ach script). That's the main thing I'm after right now -- I want to cut down on the false positives in my orphaned-symbol reports so that the actual bugs will stand out. -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by dsl2.external.hp.com (Postfix) with ESMTP id 147F9482A for ; Thu, 19 Apr 2001 21:17:52 -0600 (MDT) Date: Thu, 19 Apr 2001 21:17:49 -0600 To: "Eric S. Raymond" , Matthew Wilcox , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Message-ID: <20010419211749.I4217@zumpano.fc.hp.com> References: <20010419203639.H4217@zumpano.fc.hp.com> <20010419230009.A32500@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010419230009.A32500@thyrsus.com>; from esr@thyrsus.com on Thu, Apr 19, 2001 at 11:00:09PM -0400 From: willy@ldl.fc.hp.com (Matthew Wilcox) Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote: > What is the right procedure for doing changes like this? Is "don't > touch that tree" a permanent condition, or am I going to get a chance > to clean up the global CONFIG_ namespace after your next merge-down? Our current status is that we've got a patch with Alan that's been sitting in his tree for a while (things got trickier than he expected and he hasn't been able to merge that upstream to Linus yet). Meanwhile we've carried on development as normal. So even after the patches in Alan's tree land, we've still got a fair hunk of changes to go in. My preference would be for you to fetch our tree cvs -d :pserver:anonymous@puffin.external.hp.com:/home/cvs/parisc login [no password] cvs -d :pserver:anonymous@puffin.external.hp.com:/home/cvs/parisc co linux and submit patches to us, which will get to Linus in the fullness of time. I'm aware this might not be terribly satisfactory for you, but we're doing our best not to lose our way amid the churn of development right now and having patches which haven't followed a progression through us makes that significantly harder. > Could I ask you to audit your tree and change the prefix on any > CONFIG_ symbols that are private over there? This would make life > easier for my auditing tools (kxref and Stephen Cole's ach script). I don't think we have any of those. We certainly have symbols which are defined for symmetry and may not actually be used yet (CONFIG_PA11 might not be, perhaps). But that's what happens when you're developing software :-) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pipt.oz.cc.utah.edu (pipt.oz.cc.utah.edu [155.99.2.7]) by dsl2.external.hp.com (Postfix) with ESMTP id 91E66482A for ; Thu, 19 Apr 2001 22:09:24 -0600 (MDT) Date: Thu, 19 Apr 2001 22:07:22 -0600 (MDT) From: james rich Sender: james.rich@m.cc.utah.edu To: Matthew Wilcox Cc: "Eric S. Raymond" , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010419211749.I4217@zumpano.fc.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: On Thu, 19 Apr 2001, Matthew Wilcox wrote: > On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote: > > What is the right procedure for doing changes like this? Is "don't > > touch that tree" a permanent condition, or am I going to get a chance > > to clean up the global CONFIG_ namespace after your next merge-down? > [snip] > My preference would be for you to fetch our tree > and submit patches to us, which will get to Linus in the fullness of time. Truly this is not meant to be negative - don't take it as such. Doesn't this seem a little like the problems occurring with lvm right now? A separate tree maintained with the maintainers not wanting others submitting patches that conflict with their particular tree? It seems that any project should be able to submit any patch against The One True Tree: Linus' tree. James Rich james.rich@m.cc.utah.edu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by dsl2.external.hp.com (Postfix) with ESMTP id 1B7E8482A for ; Thu, 19 Apr 2001 22:19:17 -0600 (MDT) Date: Thu, 19 Apr 2001 22:19:16 -0600 To: james rich Cc: Matthew Wilcox , "Eric S. Raymond" , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Message-ID: <20010419221916.K4217@zumpano.fc.hp.com> References: <20010419211749.I4217@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from james.rich@m.cc.utah.edu on Thu, Apr 19, 2001 at 10:07:22PM -0600 From: willy@ldl.fc.hp.com (Matthew Wilcox) Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote: > Doesn't this seem a little like the problems occurring with lvm right now? > A separate tree maintained with the maintainers not wanting others > submitting patches that conflict with their particular tree? It seems > that any project should be able to submit any patch against The One True > Tree: Linus' tree. every single architecture has their own development tree. the pa project has not been running as long as the other ports, and has a large amount of development going on. i count 28 commits for april (so far), 75 commits for march, 187 for february and 112 for january (to the kernel tree, other parts of the port also have commit messages). linus would go insane if we sent him every single one of those patches individually. and we'd go insane trying to keep up with what he'd taken and what he'd dropped. until you've actually tried doing this, please don't attempt to criticise. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from saturn.cs.uml.edu (saturn.cs.uml.edu [129.63.8.2]) by dsl2.external.hp.com (Postfix) with ESMTP id 259C7482A for ; Thu, 19 Apr 2001 22:53:36 -0600 (MDT) From: "Albert D. Cahalan" Message-Id: <200104200452.f3K4q3X07411@saturn.cs.uml.edu> To: willy@ldl.fc.hp.com (Matthew Wilcox) Date: Fri, 20 Apr 2001 00:52:03 -0400 (EDT) Cc: james.rich@m.cc.utah.edu (james rich), willy@ldl.fc.hp.com (Matthew Wilcox), esr@thyrsus.com (Eric S. Raymond), linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010419221916.K4217@zumpano.fc.hp.com> from "Matthew Wilcox" at Apr 19, 2001 10:19:16 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: Matthew Wilcox writes: > On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote: >> Doesn't this seem a little like the problems occurring with lvm right now? >> A separate tree maintained with the maintainers not wanting others >> submitting patches that conflict with their particular tree? It seems >> that any project should be able to submit any patch against The One True >> Tree: Linus' tree. > > every single architecture has their own development tree. This sucks for users of that architecture. Also, though not applicable to PA-RISC, it sucks for sub-architecture porters. (by sub-architecture I mean: Mac, PReP, PowerCore, BeBox, etc.) It's hard enough deciding between Linus and Alan. I'm not at all happy trying to pick through obscure CVS and BitKeeper trees that might not be up-to-data with the latest mainstream bug fixes. > the pa project > has not been running as long as the other ports, and has a large amount of > development going on. i count 28 commits for april (so far), 75 commits > for march, 187 for february and 112 for january (to the kernel tree, other > parts of the port also have commit messages). linus would go insane if > we sent him every single one of those patches individually. and we'd > go insane trying to keep up with what he'd taken and what he'd dropped. > > until you've actually tried doing this, please don't attempt to criticise. Have _you_ tried? If I recall correctly, Linus spoke out against the PowerPC people doing the exact same thing. So unless you get told to quit annoying him with patches, sending them is the safe bet. Well here we go. It's about IrDA though, not PowerPC. Read it! http://lwn.net/2000/1109/a/lt-IrDA.php3 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by dsl2.external.hp.com (Postfix) with ESMTP id 66E70482A for ; Thu, 19 Apr 2001 23:20:07 -0600 (MDT) Date: Fri, 20 Apr 2001 02:17:42 -0300 (BRST) From: Rik van Riel To: "Albert D. Cahalan" Cc: Matthew Wilcox , james rich , "Eric S. Raymond" , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <200104200452.f3K4q3X07411@saturn.cs.uml.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: On Fri, 20 Apr 2001, Albert D. Cahalan wrote: > This sucks for users of that architecture. Also, though not > applicable to PA-RISC, it sucks for sub-architecture porters. > (by sub-architecture I mean: Mac, PReP, PowerCore, BeBox, etc.) As you said it so eloquently a few paragraphs down: "send patches!" cheers, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from passion.cambridge.redhat.com (dell-paw-3.cambridge.redhat.com [195.224.55.237]) by dsl2.external.hp.com (Postfix) with ESMTP id 2B410482A for ; Fri, 20 Apr 2001 02:24:33 -0600 (MDT) From: David Woodhouse In-Reply-To: References: To: james rich Cc: Matthew Wilcox , "Eric S. Raymond" , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 09:19:53 +0100 Message-ID: <14608.987754793@redhat.com> Sender: David Woodhouse Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: james.rich@m.cc.utah.edu said: > Doesn't this seem a little like the problems occurring with lvm right > now? A separate tree maintained with the maintainers not wanting > others submitting patches that conflict with their particular tree? > It seems that any project should be able to submit any patch against > The One True Tree: Linus' tree. Of course they can. Linus does apply them too. People are asking nicely that ESR not do so in this case, because merges are being planned. The contents of drivers/mtd/ are in the same situation. For some reason, I felt it inappropriate to give every patch at every stage of development to Linus for inclusion in the 2.4.0-test and 2.4.[123] kernels. Now I'm vaguely happy with it all and it's stable, I'm working on cleaning up some of the cosmetics and breaking it up into digestible patches. Doing primary development in CVS seems to work OK for me, and allows me to continue development without destabilising the One True Tree. During such times, it's useful to have a branch for the code which is in the One True Tree, so urgent fixes can be merged, and the diff against the One True Tree after each release has something to diff against to catch patches where people didn't even bother to Cc the maintainer. I believe people were _told_ to hold off until 2.4.5-ish, or when the tree became stable. Violent imagery was used to reinforce this instruction. That being the case, how about holding the config changes back until after everyone else who's been waiting has merged their pending changes? -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id 6383D482A for ; Fri, 20 Apr 2001 07:19:07 -0600 (MDT) Date: Fri, 20 Apr 2001 09:18:34 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: Matthew Wilcox , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420091834.A5102@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010419230009.A32500@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Apr 20, 2001 at 02:08:25PM +0100 List-ID: Alan Cox : > > What is the right procedure for doing changes like this? Is "don't > > touch that tree" a permanent condition, or am I going to get a chance > > to clean up the global CONFIG_ namespace after your next merge-down? > > Feeding arch related stuff to the architecture maintainers. I shall attempt it. > > That's the main thing I'm after right now -- I want to cut down on > > the false positives in my orphaned-symbol reports so that the actual > > bugs will stand out. > > Teach it to read a 'symbolstoignore' file. Someone else has already pointed out that this is not a solution that will scale well. It would substitute a continuing management headache for the cleanup that's really needed. In fact I'm reluctant to do this even for cases where it's clearly legitimate (CONFIG_BOOM, CONFIG_BOGUS :-)) partly because later on it might provide an excuse for people not to do the cleanup. > Part of the problem you are hitting right now is that most > architectures are not yet fully in sync with 2.4 nor likely to all > be for another few iterations. Understood. I'll do what I can in the architecture-independent code, then. -- Eric S. Raymond "Boys who own legal firearms have much lower rates of delinquency and drug use and are even slightly less delinquent than nonowners of guns." -- U.S. Department of Justice, National Institute of Justice, Office of Juvenile Justice and Delinquency Prevention, NCJ-143454, "Urban Delinquency and Substance Abuse," August 1995. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by dsl2.external.hp.com (Postfix) with ESMTP id 24014482A for ; Fri, 20 Apr 2001 07:20:43 -0600 (MDT) Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? To: esr@thyrsus.com Date: Fri, 20 Apr 2001 14:08:25 +0100 (BST) Cc: willy@ldl.fc.hp.com (Matthew Wilcox), linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010419230009.A32500@thyrsus.com> from "Eric S. Raymond" at Apr 19, 2001 11:00:09 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: From: Alan Cox List-ID: > What is the right procedure for doing changes like this? Is "don't > touch that tree" a permanent condition, or am I going to get a chance > to clean up the global CONFIG_ namespace after your next merge-down? Feeding arch related stuff to the architecture maintainers. > That's the main thing I'm after right now -- I want to cut down on > the false positives in my orphaned-symbol reports so that the actual > bugs will stand out. Teach it to read a 'symbolstoignore' file. Part of the problem you are hitting right now is that most architectures are not yet fully in sync with 2.4 nor likely to all be for another few iterations. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by dsl2.external.hp.com (Postfix) with ESMTP id 5B88E482A for ; Fri, 20 Apr 2001 07:26:25 -0600 (MDT) Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? To: acahalan@cs.uml.edu (Albert D. Cahalan) Date: Fri, 20 Apr 2001 14:13:35 +0100 (BST) Cc: willy@ldl.fc.hp.com (Matthew Wilcox), james.rich@m.cc.utah.edu (james rich), esr@thyrsus.com (Eric S. Raymond), linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <200104200452.f3K4q3X07411@saturn.cs.uml.edu> from "Albert D. Cahalan" at Apr 20, 2001 12:52:03 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: From: Alan Cox List-ID: > > we sent him every single one of those patches individually. and we'd > > go insane trying to keep up with what he'd taken and what he'd dropped. > > > > until you've actually tried doing this, please don't attempt to criticise. > > Have _you_ tried? If I recall correctly, Linus spoke out against the I have for one. Its definitely the wrong approach to bomb Linus with patches when doing the merge of an architecture. All the architecture folk with in their own trees for good reason. Once the code is in a fit state to merge (ie actually works well with the new 2.4.x stuff and 2.4.x core stops shifting around) then the merge can get done piece by piece. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id 4027E482A for ; Fri, 20 Apr 2001 07:36:14 -0600 (MDT) Date: Fri, 20 Apr 2001 09:35:38 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420093538.A5525@thyrsus.com> Reply-To: esr@thyrsus.com References: <200104200452.f3K4q3X07411@saturn.cs.uml.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Apr 20, 2001 at 02:13:35PM +0100 List-ID: Alan Cox : > I have for one. Its definitely the wrong approach to bomb Linus with patches > when doing the merge of an architecture. All the architecture folk with in > their own trees for good reason. On the other hand, Linus has objected to the One-Big-Patch approach in the past with respect to things like the networking and VM code. How are people to know what the right thing is? -- Eric S. Raymond Love your country, but never trust its government. -- Robert A. Heinlein. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id C155F482A for ; Fri, 20 Apr 2001 07:53:35 -0600 (MDT) Date: Fri, 20 Apr 2001 09:53:02 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420095302.A5674@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010420093538.A5525@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Apr 20, 2001 at 02:43:49PM +0100 List-ID: Alan Cox : > > Alan Cox : > > > I have for one. Its definitely the wrong approach to bomb Linus > > > with patches when doing the merge of an architecture. All the > > > architecture folk with in their own trees for good reason. > > > > On the other hand, Linus has objected to the One-Big-Patch approach in > > the past with respect to things like the networking and VM code. How > > are people to know what the right thing is? > > Who said anything about one big patch ? Just because you have a lot > of differences doesnt mean you send Linus one giant splat of code. I > don't send Linus -ac for example. OK, so maybe I'm being stupid. But the implication of this talk of separate port trees and architecture merges is that these guys periodically send big resync patches to you and Linus. If that's not what's going on, what is? -- Eric S. Raymond Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by dsl2.external.hp.com (Postfix) with ESMTP id 9B1D9482A for ; Fri, 20 Apr 2001 07:56:42 -0600 (MDT) Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? To: esr@thyrsus.com Date: Fri, 20 Apr 2001 14:43:49 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), acahalan@cs.uml.edu (Albert D. Cahalan), willy@ldl.fc.hp.com (Matthew Wilcox), james.rich@m.cc.utah.edu (james rich), linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010420093538.A5525@thyrsus.com> from "Eric S. Raymond" at Apr 20, 2001 09:35:38 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: From: Alan Cox List-ID: > Alan Cox : > > I have for one. Its definitely the wrong approach to bomb Linus with patches > > when doing the merge of an architecture. All the architecture folk with in > > their own trees for good reason. > > On the other hand, Linus has objected to the One-Big-Patch approach in > the past with respect to things like the networking and VM code. How > are people to know what the right thing is? Who said anything about one big patch ? Just because you have a lot of differences doesnt mean you send Linus one giant splat of code. I don't send Linus -ac for example. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by dsl2.external.hp.com (Postfix) with ESMTP id 9D67C482A for ; Fri, 20 Apr 2001 08:02:49 -0600 (MDT) Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? To: esr@thyrsus.com Date: Fri, 20 Apr 2001 15:03:06 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), acahalan@cs.uml.edu (Albert D. Cahalan), willy@ldl.fc.hp.com (Matthew Wilcox), james.rich@m.cc.utah.edu (james rich), linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010420095302.A5674@thyrsus.com> from "Eric S. Raymond" at Apr 20, 2001 09:53:02 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: From: Alan Cox List-ID: > OK, so maybe I'm being stupid. But the implication of this talk of separate > port trees and architecture merges is that these guys periodically send big > resync patches to you and Linus. > > If that's not what's going on, what is? People send batches of small fixes to Linus or to me. So for example the S/390 folks send me things like 'fix the mm layer to match the changes in 2.4.3' and 'Update the DASD storage driver'. Each of which fixes one thing or one set of things and is easy to check on its own From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id 4DCC1482A for ; Fri, 20 Apr 2001 08:20:28 -0600 (MDT) Date: Fri, 20 Apr 2001 10:19:51 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420101951.A6011@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010420095302.A5674@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Apr 20, 2001 at 03:03:06PM +0100 List-ID: Alan Cox : > People send batches of small fixes to Linus or to me. So for example > the S/390 folks send me things like 'fix the mm layer to match the > changes in 2.4.3' and 'Update the DASD storage driver'. Each of > which fixes one thing or one set of things and is easy to check on > its own I'll continue asking stupid questions, then. Like, under this system how can either you or the port maintainers maintain a good representation of how far out of sync they are with the main tree? The implied workflow (developers in general, up to port maintainers, up to you and Linus) makes both technological and sociological sense. It kind of reminds me of Anglo-Norman feudalism post-1066 ("No lord without land, no land without a lord."). There are a couple of funny edge cases that it doesn't seem to handle well, though. One is the kind I'm bumping into right now, where somebody legitimately needs to make small (almost trivial) changes scattered all through the tree. Another is the case where a piece of code that needs to be changed doesn't have an active maintainer for a third party like me to go to. What's the neighborly way to deal with these? -- Eric S. Raymond "The best we can hope for concerning the people at large is that they be properly armed." -- Alexander Hamilton, The Federalist Papers at 184-188 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by dsl2.external.hp.com (Postfix) with ESMTP id 4A01D482A for ; Fri, 20 Apr 2001 08:45:42 -0600 (MDT) Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? To: esr@thyrsus.com Date: Fri, 20 Apr 2001 15:44:34 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), acahalan@cs.uml.edu (Albert D. Cahalan), willy@ldl.fc.hp.com (Matthew Wilcox), james.rich@m.cc.utah.edu (james rich), linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010420101951.A6011@thyrsus.com> from "Eric S. Raymond" at Apr 20, 2001 10:19:51 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: From: Alan Cox List-ID: > I'll continue asking stupid questions, then. Like, under this system how > can either you or the port maintainers maintain a good representation of > how far out of sync they are with the main tree? diff and read the output. [bizzare sociopolitical mumble deleted] > well, though. One is the kind I'm bumping into right now, where > somebody legitimately needs to make small (almost trivial) changes > scattered all through the tree. Yep. But such changes are rare. Or should be. > Another is the case where a piece of code that needs to be changed doesn't > have an active maintainer for a third party like me to go to. > What's the neighborly way to deal with these? If I get patches for stuff that doesnt seem to have a maintainer I apply them. On the odd occasion a scream is heard in the distance it means I now know there is an active maintainer. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id D719D482A for ; Fri, 20 Apr 2001 08:59:17 -0600 (MDT) Date: Fri, 20 Apr 2001 10:59:34 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420105934.A6668@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010420101951.A6011@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Apr 20, 2001 at 03:44:34PM +0100 List-ID: Alan Cox : > > well, though. One is the kind I'm bumping into right now, where > > somebody legitimately needs to make small (almost trivial) changes > > scattered all through the tree. > > Yep. But such changes are rare. Or should be. Knowing that doesn't help me much, since I'm trying to fix up a global namespace that touches everybody :-(. > If I get patches for stuff that doesnt seem to have a maintainer I > apply them. On the odd occasion a scream is heard in the distance > it means I now know there is an active maintainer. All right then. I'm going to send you a bunch of dead-symbol cleanup patches. I'll try to stay in the mainline code and out of the port trees. Would you please do me the kindness of telling me which ones can go in and which ones you think have to go through maintainers? You should have received one such patch already, fixes for two documentation files. -- Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from opus.bloom.county (cpe-24-221-152-185.az.sprintbbd.net [24.221.152.185]) by dsl2.external.hp.com (Postfix) with ESMTP id BE071482A for ; Fri, 20 Apr 2001 09:54:18 -0600 (MDT) Date: Fri, 20 Apr 2001 08:51:48 -0700 From: Tom Rini To: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420085148.V13403@opus.bloom.county> References: <20010420101951.A6011@thyrsus.com> <20010420105934.A6668@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010420105934.A6668@thyrsus.com>; from esr@thyrsus.com on Fri, Apr 20, 2001 at 10:59:34AM -0400 List-ID: On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > Alan Cox : > > > well, though. One is the kind I'm bumping into right now, where > > > somebody legitimately needs to make small (almost trivial) changes > > > scattered all through the tree. > > > > Yep. But such changes are rare. Or should be. > > Knowing that doesn't help me much, since I'm trying to fix up a global > namespace that touches everybody :-(. Which does boil down to having to work with trees other than Linus or Alans. Remember, the official tree is not always the up-to-date tree, or in the case of other arches, the most relevant tree. But if you send something off to a maintainer, there's a good chance (if they're still active) they'll do what you ask, and it'll get to Linus/Alan the next time they sync. As long as the problem gets fixed, it shouldn't be as important if it's fixed in everyones tree right now, or in a release or two. If it's some sort of huge bug it just might get fixed sooner. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from havoc.gtf.org (panic.ohr.gatech.edu [130.207.47.194]) by dsl2.external.hp.com (Postfix) with ESMTP id B5796482A for ; Fri, 20 Apr 2001 10:06:27 -0600 (MDT) Sender: jgarzik@havoc.gtf.org Message-ID: <3AE05E7C.F9C76ED2@mandrakesoft.com> Date: Fri, 20 Apr 2001 12:06:20 -0400 From: Jeff Garzik MIME-Version: 1.0 To: Tom Rini Cc: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? References: <20010420101951.A6011@thyrsus.com> <20010420105934.A6668@thyrsus.com> <20010420085148.V13403@opus.bloom.county> Content-Type: text/plain; charset=us-ascii List-ID: Tom Rini wrote: > Which does boil down to having to work with trees other than Linus or > Alans. Remember, the official tree is not always the up-to-date tree, > or in the case of other arches, the most relevant tree. Yep. You could even look at Linus as simply the x86 port maintainer :) Except for alpha and x86, AFAIK, most people wind up going through arch-specific channels to get their kernels... -- Jeff Garzik | The difference between America and England is that Building 1024 | the English think 100 miles is a long distance and MandrakeSoft | the Americans think 100 years is a long time. | (random fortune) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from draal.physics.wisc.edu (draal.physics.wisc.edu [128.104.137.82]) by dsl2.external.hp.com (Postfix) with ESMTP id 5981C482A for ; Fri, 20 Apr 2001 10:15:50 -0600 (MDT) Date: Fri, 20 Apr 2001 11:15:12 -0500 From: Bob McElrath To: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420111512.H22687@draal.physics.wisc.edu> References: <20010420101951.A6011@thyrsus.com> <20010420105934.A6668@thyrsus.com> <20010420085148.V13403@opus.bloom.county> <3AE05E7C.F9C76ED2@mandrakesoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1y6imfT/xHuCvpN0" In-Reply-To: <3AE05E7C.F9C76ED2@mandrakesoft.com>; from jgarzik@mandrakesoft.com on Fri, Apr 20, 2001 at 12:06:20PM -0400 List-ID: --1y6imfT/xHuCvpN0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jeff Garzik [jgarzik@mandrakesoft.com] wrote: > Tom Rini wrote: > > Which does boil down to having to work with trees other than Linus or > > Alans. Remember, the official tree is not always the up-to-date tree, > > or in the case of other arches, the most relevant tree. >=20 > Yep. You could even look at Linus as simply the x86 port maintainer :) >=20 > Except for alpha and x86, AFAIK, most people wind up going through > arch-specific channels to get their kernels... This may be a dumb question, but is there some place where the arch maintainers are listed? Where the arch-specific trees are kept? Where would I go to get the latest set of relevant patches for alpha? Grepping the Documentation/ directory for "alpha" I see nothing relevant. IMHO this should all be listend in one place. Maybe Documentation/Arch-Maintainers.txt. Cheers, -- Bob Bob McElrath (rsmcelrath@students.wisc.edu)=20 Univ. of Wisconsin at Madison, Department of Physics --1y6imfT/xHuCvpN0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjrgYJAACgkQjwioWRGe9K1jIgCfSwKD0hGWuEuYC3/aEEqaR09h AKgAoKtY2hXAL14cUCvfNqj/8g9otPWV =yto2 -----END PGP SIGNATURE----- --1y6imfT/xHuCvpN0-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by dsl2.external.hp.com (Postfix) with ESMTP id 7B4FF482A for ; Fri, 20 Apr 2001 10:21:33 -0600 (MDT) Received: from willy by www.linux.org.uk with local (Exim 3.13 #1) id 14qdew-0006Sf-00; Fri, 20 Apr 2001 17:21:26 +0100 Date: Fri, 20 Apr 2001 17:21:26 +0100 From: Matthew Wilcox To: Bob McElrath Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420172126.C18464@parcelfarce.linux.theplanet.co.uk> References: <20010420101951.A6011@thyrsus.com> <20010420105934.A6668@thyrsus.com> <20010420085148.V13403@opus.bloom.county> <3AE05E7C.F9C76ED2@mandrakesoft.com> <20010420111512.H22687@draal.physics.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010420111512.H22687@draal.physics.wisc.edu>; from rsmcelrath@students.wisc.edu on Fri, Apr 20, 2001 at 11:15:12AM -0500 Sender: List-ID: On Fri, Apr 20, 2001 at 11:15:12AM -0500, Bob McElrath wrote: > This may be a dumb question, but is there some place where the arch > maintainers are listed? Where the arch-specific trees are kept? Where > would I go to get the latest set of relevant patches for alpha? http://www.kernel.org/ has a list of architecture websites. Also the CREDITS / MAINTAINERS files tend to list the people who are involved. -- Revolutions do not require corporate support. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from havoc.gtf.org (panic.ohr.gatech.edu [130.207.47.194]) by dsl2.external.hp.com (Postfix) with ESMTP id 2E2C2482A for ; Fri, 20 Apr 2001 10:26:37 -0600 (MDT) Sender: jgarzik@havoc.gtf.org Message-ID: <3AE0632E.61B20C0A@mandrakesoft.com> Date: Fri, 20 Apr 2001 12:26:22 -0400 From: Jeff Garzik MIME-Version: 1.0 To: Bob McElrath Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? References: <20010420101951.A6011@thyrsus.com> <20010420105934.A6668@thyrsus.com> <20010420085148.V13403@opus.bloom.county> <3AE05E7C.F9C76ED2@mandrakesoft.com> <20010420111512.H22687@draal.physics.wisc.edu> Content-Type: text/plain; charset=us-ascii List-ID: Bob McElrath wrote: > > Jeff Garzik [jgarzik@mandrakesoft.com] wrote: > > Tom Rini wrote: > > > Which does boil down to having to work with trees other than Linus or > > > Alans. Remember, the official tree is not always the up-to-date tree, > > > or in the case of other arches, the most relevant tree. > > > > Yep. You could even look at Linus as simply the x86 port maintainer :) > > > > Except for alpha and x86, AFAIK, most people wind up going through > > arch-specific channels to get their kernels... > > This may be a dumb question, but is there some place where the arch > maintainers are listed? Where the arch-specific trees are kept? Where > would I go to get the latest set of relevant patches for alpha? As I noted in the e-mail to which you replied, there is no separate alpha tree nor arch-specific channel for alpha kernels. Generally fixes to the Alpha tree appear quickly and get merged quickly, and the tree stays in sync quite well. Watch linux-kernel or Alan Cox's patchkit for Alpha fixes that may be in transmit to Linus. There are of course RedHat's alpha distro, and various mailing lists on http://www.alphalinux.org/ -- Jeff Garzik | The difference between America and England is that Building 1024 | the English think 100 miles is a long distance and MandrakeSoft | the Americans think 100 years is a long time. | (random fortune) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xanadu.home (modemcable084.137-200-24.mtl.mc.videotron.ca [24.200.137.84]) by dsl2.external.hp.com (Postfix) with ESMTP id 3BE60482A for ; Fri, 20 Apr 2001 10:36:34 -0600 (MDT) Date: Fri, 20 Apr 2001 12:35:12 -0400 (EDT) From: Nicolas Pitre To: Tom Rini Cc: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: <20010420085148.V13403@opus.bloom.county> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-ID: On Fri, 20 Apr 2001, Tom Rini wrote: > On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > > Alan Cox : > > > > well, though. One is the kind I'm bumping into right now, where > > > > somebody legitimately needs to make small (almost trivial) changes > > > > scattered all through the tree. > > > > > > Yep. But such changes are rare. Or should be. > > > > Knowing that doesn't help me much, since I'm trying to fix up a global > > namespace that touches everybody :-(. > > Which does boil down to having to work with trees other than Linus or > Alans. Remember, the official tree is not always the up-to-date tree, > or in the case of other arches, the most relevant tree. But if you send > something off to a maintainer, there's a good chance (if they're still active) > they'll do what you ask, and it'll get to Linus/Alan the next time they sync. > As long as the problem gets fixed, it shouldn't be as important if it's fixed > in everyones tree right now, or in a release or two. If it's some sort of > huge bug it just might get fixed sooner. Guys, There is kind of a ridiculous situation here where people want to withhold their own changes in their own trees for all good reasons until it is mature and stable enough to be fed upstream in the appropriate way, while insisting for Linus' tree to remain incomplete and inconsistent. And we're not talking about deep architectural changes here -- only about configure symbols and help text. Why not having everybody's tree consistent with themselves and have whatever CONFIGURE_* symbols and help text be merged along with the very code it refers to? It's worthless to have config symbols be merged into Linus' or Alan's tree if the code isn't there (yet). It simply makes no sense. This might shift some of the namespace consistency work to architecture maintainers (which is a good thing IMHO) and establish the basis for yet a more sanitized kernel.org tree at all times for before and after any further patches are merged. I'm myself maintainer of a subarchitecture and removing currently unreferenced SA1100 config symbols from the official Linux tree would probably give me a one-time effort to bring them back in my tree but this is certainly for a saner code/namespace distribution in general. Why should the symbols I maintain remain there if I'm not ready yet to sync up the code they refer to? Hey this is only CONFIG_ symbols after all. If they get removed now, they will only reappear _with_ the code they refer to eventually when it'll get merged. Nicolas From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id 3FAC4482A for ; Fri, 20 Apr 2001 10:51:06 -0600 (MDT) Date: Fri, 20 Apr 2001 12:50:05 -0400 From: "Eric S. Raymond" To: Nicolas Pitre Cc: Tom Rini , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420125005.B8086@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010420085148.V13403@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from nico@cam.org on Fri, Apr 20, 2001 at 12:35:12PM -0400 List-ID: Nicolas Pitre : > Why not having everybody's tree consistent with themselves and have whatever > CONFIGURE_* symbols and help text be merged along with the very code it > refers to? It's worthless to have config symbols be merged into Linus' or > Alan's tree if the code isn't there (yet). It simply makes no sense. And now it has a cost, too. It makes finding real bugs more difficult. -- Eric S. Raymond Every election is a sort of advance auction sale of stolen goods. -- H.L. Mencken From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ccure.karaya.com (mnh-1-16.mv.com [207.22.10.48]) by dsl2.external.hp.com (Postfix) with ESMTP id BD8A7482A for ; Fri, 20 Apr 2001 11:47:37 -0600 (MDT) Message-Id: <200104201900.OAA03252@ccure.karaya.com> To: Matthew Wilcox Cc: Bob McElrath Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: Your message of "Fri, 20 Apr 2001 17:21:26 +0100." <20010420172126.C18464@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 14:00:00 -0500 From: Jeff Dike matthew@wil.cx said: > http://www.kernel.org/ has a list of architecture websites. Also the > CREDITS / MAINTAINERS files tend to list the people who are involved. Except it's restricted to processor ports, which would leave you not knowing about UML. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from opus.bloom.county (cpe-24-221-152-185.az.sprintbbd.net [24.221.152.185]) by dsl2.external.hp.com (Postfix) with ESMTP id C7EDF482A for ; Fri, 20 Apr 2001 12:22:47 -0600 (MDT) Date: Fri, 20 Apr 2001 11:20:42 -0700 From: Tom Rini To: Nicolas Pitre Cc: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420112042.Z13403@opus.bloom.county> References: <20010420085148.V13403@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from nico@cam.org on Fri, Apr 20, 2001 at 12:35:12PM -0400 List-ID: On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: > There is kind of a ridiculous situation here where people want to withhold > their own changes in their own trees for all good reasons until it is mature > and stable enough to be fed upstream in the appropriate way, while insisting > for Linus' tree to remain incomplete and inconsistent. And we're not > talking about deep architectural changes here -- only about configure > symbols and help text. The answer is simple, noise. > Why not having everybody's tree consistent with themselves and have whatever > CONFIGURE_* symbols and help text be merged along with the very code it > refers to? It's worthless to have config symbols be merged into Linus' or > Alan's tree if the code isn't there (yet). It simply makes no sense. Well, this depends a lot on a) The project to be merged (arch, mtd, whatever) and b) how far something has gotten in being merged someplace else, and of course c) the maintainer(s). Whatever the exact case, and in general, it should be handled via the maintainer. Why? They maintain the code. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by dsl2.external.hp.com (Postfix) with ESMTP id DBB3D482A for ; Fri, 20 Apr 2001 12:47:06 -0600 (MDT) Received: from willy by www.linux.org.uk with local (Exim 3.13 #1) id 14qfvq-0001Ss-00; Fri, 20 Apr 2001 19:47:02 +0100 Date: Fri, 20 Apr 2001 19:47:02 +0100 From: Matthew Wilcox To: Jeff Dike Cc: Matthew Wilcox , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420194702.E18464@parcelfarce.linux.theplanet.co.uk> References: <20010420172126.C18464@parcelfarce.linux.theplanet.co.uk> <200104201900.OAA03252@ccure.karaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200104201900.OAA03252@ccure.karaya.com>; from jdike@karaya.com on Fri, Apr 20, 2001 at 02:00:00PM -0500 Sender: List-ID: On Fri, Apr 20, 2001 at 02:00:00PM -0500, Jeff Dike wrote: > matthew@wil.cx said: > > http://www.kernel.org/ has a list of architecture websites. Also the > > CREDITS / MAINTAINERS files tend to list the people who are involved. > > Except it's restricted to processor ports, which would leave you not knowing > about UML. Have you tried mailing webmaster@kernel.org and asking to be added? -- Revolutions do not require corporate support. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xanadu.home (modemcable084.137-200-24.mtl.mc.videotron.ca [24.200.137.84]) by dsl2.external.hp.com (Postfix) with ESMTP id F2B8E482A for ; Fri, 20 Apr 2001 12:49:48 -0600 (MDT) Date: Fri, 20 Apr 2001 14:48:18 -0400 (EDT) From: Nicolas Pitre To: Tom Rini Cc: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: <20010420112042.Z13403@opus.bloom.county> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-ID: On Fri, 20 Apr 2001, Tom Rini wrote: > On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: > > > Why not having everybody's tree consistent with themselves and have whatever > > CONFIGURE_* symbols and help text be merged along with the very code it > > refers to? It's worthless to have config symbols be merged into Linus' or > > Alan's tree if the code isn't there (yet). It simply makes no sense. > > Well, this depends a lot on a) The project to be merged (arch, mtd, whatever) > and b) how far something has gotten in being merged someplace else, and of > course c) the maintainer(s). Whatever the exact case, and in general, it > should be handled via the maintainer. Why? They maintain the code. Therefore it's the maintainer's job to submit coherent patches and accept to see inconsistent CONFIG_* references be removed from the official tree until further patch submission is due. It's only a question of discipline. Otherwise how can you distinguish between dead wood which must be removed and potentially valid symbols referring to code existing only in a remote tree? Nicolas From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by dsl2.external.hp.com (Postfix) with ESMTP id F1D78482A for ; Fri, 20 Apr 2001 12:54:45 -0600 (MDT) Sender: Jes.Sorensen@cern.ch To: Jeff Dike Cc: Matthew Wilcox , Bob McElrath , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? References: <200104201900.OAA03252@ccure.karaya.com> From: Jes Sorensen Date: 20 Apr 2001 20:53:32 +0200 In-Reply-To: Jeff Dike's message of "Fri, 20 Apr 2001 14:00:00 -0500" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-ID: >>>>> "Jeff" == Jeff Dike writes: Jeff> matthew@wil.cx said: >> http://www.kernel.org/ has a list of architecture websites. Also >> the CREDITS / MAINTAINERS files tend to list the people who are >> involved. Jeff> Except it's restricted to processor ports, which would leave you Jeff> not knowing about UML. I'd be highly surprised if they said no to adding UML to the list if you mailed them a request to update the page. Jes From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by dsl2.external.hp.com (Postfix) with ESMTP id 516A6482A for ; Fri, 20 Apr 2001 12:54:52 -0600 (MDT) Received: from dyn-33.linux.theplanet.co.uk ([195.92.244.33] helo=caramon.arm.linux.org.uk) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 14qfyo-0001W1-00; Fri, 20 Apr 2001 19:50:06 +0100 Received: from flint.arm.linux.org.uk (IDENT:root@flint.arm.linux.org.uk [192.168.0.4]) by caramon.arm.linux.org.uk (8.11.0/8.11.0) with ESMTP id f3KIo5b01850; Fri, 20 Apr 2001 19:50:05 +0100 Received: (from rmk@localhost) by flint.arm.linux.org.uk (8.11.0/8.11.0) id f3KIo4s06295; Fri, 20 Apr 2001 19:50:04 +0100 Date: Fri, 20 Apr 2001 19:50:04 +0100 From: Russell King To: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420195004.A5510@flint.arm.linux.org.uk> References: <20010420101951.A6011@thyrsus.com> <20010420105934.A6668@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010420105934.A6668@thyrsus.com>; from esr@thyrsus.com on Fri, Apr 20, 2001 at 10:59:34AM -0400 List-ID: On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > All right then. I'm going to send you a bunch of dead-symbol cleanup > patches. I'll try to stay in the mainline code and out of the port > trees. Would you please do me the kindness of telling me which ones > can go in and which ones you think have to go through maintainers? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from onet2.cup.hp.com (onet2.cup.hp.com [15.255.208.3]) by dsl2.external.hp.com (Postfix) with ESMTP id BBA1E482A for ; Fri, 20 Apr 2001 12:57:04 -0600 (MDT) Received: from opus.bloom.county (cpe-24-221-152-185.az.sprintbbd.net [24.221.152.185]) by onet2.cup.hp.com (Postfix) with ESMTP id D10B218D11 for ; Fri, 20 Apr 2001 11:57:01 -0700 (PDT) Date: Fri, 20 Apr 2001 11:55:01 -0700 From: Tom Rini To: Nicolas Pitre Cc: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420115501.A13403@opus.bloom.county> References: <20010420112042.Z13403@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from nico@cam.org on Fri, Apr 20, 2001 at 02:48:18PM -0400 List-ID: On Fri, Apr 20, 2001 at 02:48:18PM -0400, Nicolas Pitre wrote: > > > On Fri, 20 Apr 2001, Tom Rini wrote: > > > On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: > > > > > Why not having everybody's tree consistent with themselves and have whatever > > > CONFIGURE_* symbols and help text be merged along with the very code it > > > refers to? It's worthless to have config symbols be merged into Linus' or > > > Alan's tree if the code isn't there (yet). It simply makes no sense. > > > > Well, this depends a lot on a) The project to be merged (arch, mtd, whatever) > > and b) how far something has gotten in being merged someplace else, and of > > course c) the maintainer(s). Whatever the exact case, and in general, it > > should be handled via the maintainer. Why? They maintain the code. > > Therefore it's the maintainer's job to submit coherent patches and accept to > see inconsistent CONFIG_* references be removed from the official tree until > further patch submission is due. It's only a question of discipline. > Otherwise how can you distinguish between dead wood which must be removed > and potentially valid symbols referring to code existing only in a remote > tree? Er, I think we agree, but I'm not sure. :) The only people who actually know the difference between dead wood and partily merged code are the maintainers. IMHO it's silly to remove a piece of code like: #ifdef CONFIG_SOMETHING_NOT_MERGED ... #endif If the rest of the code, which would make the above useful is heading toward Linus. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by dsl2.external.hp.com (Postfix) with ESMTP id 6B217482A for ; Fri, 20 Apr 2001 13:09:39 -0600 (MDT) Received: from dyn-33.linux.theplanet.co.uk ([195.92.244.33] helo=caramon.arm.linux.org.uk) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 14qgH7-00024a-00; Fri, 20 Apr 2001 20:09:01 +0100 Received: from flint.arm.linux.org.uk (IDENT:root@flint.arm.linux.org.uk [192.168.0.4]) by caramon.arm.linux.org.uk (8.11.0/8.11.0) with ESMTP id f3KJ90b01904; Fri, 20 Apr 2001 20:09:00 +0100 Received: (from rmk@localhost) by flint.arm.linux.org.uk (8.11.0/8.11.0) id f3KJ8xp06357; Fri, 20 Apr 2001 20:08:59 +0100 Date: Fri, 20 Apr 2001 20:08:59 +0100 From: Russell King To: "Eric S. Raymond" , Nicolas Pitre , Tom Rini , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420200859.B5510@flint.arm.linux.org.uk> References: <20010420085148.V13403@opus.bloom.county> <20010420125005.B8086@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010420125005.B8086@thyrsus.com>; from esr@thyrsus.com on Fri, Apr 20, 2001 at 12:50:05PM -0400 List-ID: On Fri, Apr 20, 2001 at 12:50:05PM -0400, Eric S. Raymond wrote: > Nicolas Pitre : > > Why not having everybody's tree consistent with themselves and have whatever > > CONFIGURE_* symbols and help text be merged along with the very code it > > refers to? It's worthless to have config symbols be merged into Linus' or > > Alan's tree if the code isn't there (yet). It simply makes no sense. Really, the above issue is down to the sub-architecture maintainers splitting up their patches into the "one feature, one bug" thing, rather than "one set of files" (which, incidentally I'm guilty of as well). That way, when stuff gets added, you get: 1. The C source changes for that item 2. The configure script stuff for that one item 3. The help text for that one item. Currently, stuff that comes to me appears mostly as "here's a configure update", "here's a PCMCIA update", etc. I'll pull out an instance from my patch tracking system (sorry, Philip, yours is the first one I found): Patch 413/1 (see http://www.arm.linux.org.uk/developer/patches/?id=413/1&mode=patch) This patch adds the defconfig file for the CLPS7500 architecture, and it contains symbols such as: CONFIG_BLK_DEV_FLD7500 CONFIG_CLPS7500_FLASH Neither of these two drivers are currently in Linus' tree, or in fact my tree. Should I reject the patch? Should I accept it and edit these out, or what? > And now it has a cost, too. It makes finding real bugs more difficult. Well, if they get removed in Linus tree, then when I next sync, they'll get re-added, or maybe they won't. Then someone else will remove them, then they'll get re-added ad infinitum. This also touches on another issue - patch. I've had several times where I've sent Alan stuff, its gone up to Linus, I receive it back, and during the merge, patch does its stuff without complaining (because there is not enough context in the diff). Typically, this happens in the Configure.help file. Generally it seems like diff needs to produce one more line of context, and most of these problems will go away. Yes, there will still be the odd problem, so then it becomes the "how much do you crank the setting" problem. -- 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: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id B07CB482A for ; Fri, 20 Apr 2001 13:48:08 -0600 (MDT) Date: Fri, 20 Apr 2001 15:47:43 -0400 From: "Eric S. Raymond" To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Message-ID: <20010420154743.A19618@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010419203639.H4217@zumpano.fc.hp.com> <20010419230009.A32500@thyrsus.com> <20010419211749.I4217@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010419211749.I4217@zumpano.fc.hp.com>; from willy@ldl.fc.hp.com on Thu, Apr 19, 2001 at 09:17:49PM -0600 Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: Matthew Wilcox : > > Could I ask you to audit your tree and change the prefix on any > > CONFIG_ symbols that are private over there? This would make life > > easier for my auditing tools (kxref and Stephen Cole's ach script). > > I don't think we have any of those. We certainly have symbols which are > defined for symmetry and may not actually be used yet (CONFIG_PA11 might not > be, perhaps). But that's what happens when you're developing software :-) Here's what I have for you guys: CONFIG_BINFMT_JAVA: arch/parisc/config.in arch/parisc/defconfig arch/cris/config.in arch/cris/defconfig You've already gotten rid of that one. CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig Not used in code anywhere. Can you get rid of this one? CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c CONFIG_FUNC_SIZE: arch/parisc/kernel/sba_iommu.c Would you please take these out of the CONFIG_ namespace? Changing the prefix to CONFIGURE would do nicely. CONFIG_GENRTC: arch/parisc/defconfig This is a typo for GEN_RTC. Please fix it or get rid of it. CONFIG_HIL: arch/parisc/defconfig Looks like an orphan. Can you get rid of it? CONFIG_GSC: arch/parisc/config.in arch/parisc/defconfig CONFIG_GSC_DINO: arch/parisc/config.in arch/parisc/defconfig CONFIG_GSC_LASI: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/led.c CONFIG_GSC_PS2: arch/parisc/config.in arch/parisc/defconfig CONFIG_IODC_CONSOLE: arch/parisc/config.in arch/parisc/kernel/setup.c CONFIG_IOMMU_CCIO: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile CONFIG_IOMMU_SBA: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile CONFIG_IOSAPIC: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile CONFIG_KWDB: arch/parisc/Makefile arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/entry.S arch/parisc/kernel/traps.c arch/parisc/mm/init.c CONFIG_LASI_82596: arch/parisc/config.in arch/parisc/defconfig CONFIG_PARPORT_GSC: drivers/parport/Makefile arch/parisc/config.in arch/parisc/defconfig CONFIG_PCI_LBA: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile CONFIG_SCSI_LASI: arch/parisc/config.in arch/parisc/defconfig CONFIG_SCSI_ZALON: arch/parisc/config.in arch/parisc/defconfig CONFIG_STI_CONSOLE: arch/parisc/Makefile arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/setup.c arch/parisc/mm/init.c Looks like these need Configure.help entries. CONFIG_SERIAL_GSC: drivers/char/serial.c arch/parisc/defconfig That reference pattern looks kind of weird. Is this a bug? If you could clean these up, that's everything I need from the parisc tree. -- 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: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by dsl2.external.hp.com (Postfix) with ESMTP id 328AC482A for ; Fri, 20 Apr 2001 14:00:24 -0600 (MDT) Date: Fri, 20 Apr 2001 14:00:03 -0600 To: "Eric S. Raymond" , Matthew Wilcox , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Message-ID: <20010420140003.M4217@zumpano.fc.hp.com> References: <20010419203639.H4217@zumpano.fc.hp.com> <20010419230009.A32500@thyrsus.com> <20010419211749.I4217@zumpano.fc.hp.com> <20010420154743.A19618@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010420154743.A19618@thyrsus.com>; from esr@thyrsus.com on Fri, Apr 20, 2001 at 03:47:43PM -0400 From: willy@ldl.fc.hp.com (Matthew Wilcox) Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: On Fri, Apr 20, 2001 at 03:47:43PM -0400, Eric S. Raymond wrote: > CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig > > Not used in code anywhere. Can you get rid of this one? Code not merged yet. > CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c > CONFIG_FUNC_SIZE: arch/parisc/kernel/sba_iommu.c > > Would you please take these out of the CONFIG_ namespace? Changing the > prefix to CONFIGURE would do nicely. Grant? This is your code. > CONFIG_GENRTC: arch/parisc/defconfig > > This is a typo for GEN_RTC. Please fix it or get rid of it. in our tree it's in drivers/char/Makefile: obj-$(CONFIG_GENRTC) += genrtc.o this code was written by Sam Creasey as part of the sun3 port, and he schlepped it into our tree too. we have no GEN_RTC in our tree. > CONFIG_HIL: arch/parisc/defconfig > > Looks like an orphan. Can you get rid of it? code not yet merged. > CONFIG_SERIAL_GSC: drivers/char/serial.c arch/parisc/defconfig > > That reference pattern looks kind of weird. Is this a bug? it's old and needs to die properly. i haven't had time to fix that yet. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id 88308482A for ; Fri, 20 Apr 2001 14:13:33 -0600 (MDT) Date: Fri, 20 Apr 2001 16:13:04 -0400 From: "Eric S. Raymond" To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Message-ID: <20010420161304.A19954@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010419203639.H4217@zumpano.fc.hp.com> <20010419230009.A32500@thyrsus.com> <20010419211749.I4217@zumpano.fc.hp.com> <20010420154743.A19618@thyrsus.com> <20010420140003.M4217@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010420140003.M4217@zumpano.fc.hp.com>; from willy@ldl.fc.hp.com on Fri, Apr 20, 2001 at 02:00:03PM -0600 Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: Matthew Wilcox : > Code not merged yet. : > it's old and needs to die properly. i haven't had time to fix that yet. Thanks for the information. Actually the parisc tree is one of the ones that leaks the fewest of these symbols... -- Eric S. Raymond Ideology, politics and journalism, which luxuriate in failure, are impotent in the face of hope and joy. -- P. J. O'Rourke From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ccure.karaya.com (mnh-1-15.mv.com [207.22.10.47]) by dsl2.external.hp.com (Postfix) with ESMTP id 5AEF0482A for ; Fri, 20 Apr 2001 14:42:41 -0600 (MDT) Message-Id: <200104202155.QAA04046@ccure.karaya.com> To: Matthew Wilcox Cc: Bob McElrath , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: Your message of "Fri, 20 Apr 2001 19:47:02 +0100." <20010420194702.E18464@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 16:55:18 -0500 From: Jeff Dike List-ID: matthew@wil.cx said: > Have you tried mailing webmaster@kernel.org and asking to be added? Yes. jes@linuxcare.com said: > I'd be highly surprised if they said no to adding UML to the list if > you mailed them a request to update the page. Well, be surprised then. The reply from hpa was that that list was for processor ports. He did say that there might at some point in the future be a separate list (off the main page) of other things. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by dsl2.external.hp.com (Postfix) with ESMTP id C8278482A for ; Fri, 20 Apr 2001 14:54:48 -0600 (MDT) To: esr@thyrsus.com Date: Fri, 20 Apr 2001 21:55:14 +0100 (BST) Cc: willy@ldl.fc.hp.com (Matthew Wilcox), linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010420154743.A19618@thyrsus.com> from "Eric S. Raymond" at Apr 20, 2001 03:47:43 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: From: Alan Cox Subject: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? List-ID: > CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig > Not used in code anywhere. Can you get rid of this one? Its used in the parisc tree as are most of the others you see. You probably want to simply skip processing arch/parisc From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from passion.cambridge.redhat.com (dell-paw-3.cambridge.redhat.com [195.224.55.237]) by dsl2.external.hp.com (Postfix) with ESMTP id 0208E482A for ; Fri, 20 Apr 2001 15:24:05 -0600 (MDT) From: David Woodhouse In-Reply-To: References: To: Nicolas Pitre Cc: Tom Rini , "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 22:19:08 +0100 Message-ID: <6817.987801548@redhat.com> Sender: David Woodhouse List-ID: nico@cam.org said: > Therefore it's the maintainer's job to submit coherent patches and > accept to see inconsistent CONFIG_* references be removed from the > official tree until further patch submission is due. Maybe. But you tend to include the latest MTD code in your tree, for example, and hence the defconfigs have the new options in. Is it really worth your time to produce separate defconfigs without it before feeding your changes upstream? > Otherwise how can you distinguish between dead wood which must be > removed and potentially valid symbols referring to code existing only > in a remote tree? By periodically publishing a list of the potentially-obsolete symbols as ESR has done, and _not_ removing the ones which people speak up about. It's not as if this is something which needs to be done more than about once a year. -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from webber.adilger.int (h24-65-193-28.cg.shawcable.net [24.65.193.28]) by dsl2.external.hp.com (Postfix) with ESMTP id 3206A482A for ; Fri, 20 Apr 2001 15:24:35 -0600 (MDT) From: Andreas Dilger Message-Id: <200104202123.f3KLNWSm031572@webber.adilger.int> Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: <20010420195004.A5510@flint.arm.linux.org.uk> "from Russell King at Apr 20, 2001 07:50:04 pm" To: Russell King Date: Fri, 20 Apr 2001 15:23:32 -0600 (MDT) Cc: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org MIME-Version: 1.0 List-ID: Russell King writes: > - Secondly, its very easy to miss stuff in the lkml hunk of email each > day when you have less than 4 hours to read it and think about it. > (note that architecture maintainers have to read mail from their > side which may not be on lkml, think about that, think about bug fixes, > possible impacts of fixes on other machines, etc etc). Therefore, > copying their email address registered in the MAINTAINER file means > that they should not overlook your patch. One of the issues for contacting each MAINTAINER is that this information is out-of-line from the actual kernel tree. The other is that the description of what a maintainer is actually controlling is somewhat vague. How about the following: - each directory has a MAINTAINERS file which lists parties with a vested interest in files in that directory (format is mostly the same as current) - subdirectories which don't have a MAINTAINERS file use the MAINTAINERS file of the parent (or grandparent) directory - each maintainer entry explicitly lists each file/directory that this person is interested in, maybe "F: {file | directory} ...". I'm sure Eric can come up with a simple program to parse the MAINTAINER file/tree. If the program takes a kernel-tree relative filename and spit out the name/email of the relevant maintainer (subsystem and port specific mailing lists should also be included), that would make the job of finding out who to send patches to a whole lot easier. My one gripe about the MAINTAINERS file is that it still lists Remy Card as EXT2 maintainer, so we would probably need to do a find on the whole kernel tree, email each address a list of files that they "maintain" and wait until they complain, agree, or time out. Once the database is up-to-date, it simplifies the job of keeping maintainers (and other interested parties) in the loop. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id 2D9F2482A for ; Fri, 20 Apr 2001 15:25:34 -0600 (MDT) Date: Fri, 20 Apr 2001 17:24:35 -0400 From: "Eric S. Raymond" To: David Woodhouse Cc: Nicolas Pitre , Tom Rini , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420172435.A21252@thyrsus.com> Reply-To: esr@thyrsus.com References: <6817.987801548@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <6817.987801548@redhat.com>; from dwmw2@infradead.org on Fri, Apr 20, 2001 at 10:19:08PM +0100 List-ID: David Woodhouse : > > Otherwise how can you distinguish between dead wood which must be > > removed and potentially valid symbols referring to code existing only > > in a remote tree? > > By periodically publishing a list of the potentially-obsolete symbols as ESR > has done, and _not_ removing the ones which people speak up about. It's not > as if this is something which needs to be done more than about once a year. Not good enough. In a year, the pile of false positives would get high enough to make it too hard to spot real bugs like the Aironet mismatch. The whole point of the cleanup is to be able to mechanize the consistency checks so they require a minimum of human judgment. -- Eric S. Raymond "This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing government, they can exercise their constitutional right of amending it or their revolutionary right to dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from passion.cambridge.redhat.com (dell-paw-3.cambridge.redhat.com [195.224.55.237]) by dsl2.external.hp.com (Postfix) with ESMTP id 0FFFF482A for ; Fri, 20 Apr 2001 15:30:34 -0600 (MDT) From: David Woodhouse In-Reply-To: <20010420172435.A21252@thyrsus.com> References: <20010420172435.A21252@thyrsus.com> <6817.987801548@redhat.com> To: esr@thyrsus.com Cc: Nicolas Pitre , Tom Rini , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 22:29:00 +0100 Message-ID: <7043.987802140@redhat.com> Sender: David Woodhouse List-ID: esr@thyrsus.com said: > Not good enough. In a year, the pile of false positives would get > high enough to make it too hard to spot real bugs like the Aironet > mismatch. The whole point of the cleanup is to be able to mechanize > the consistency checks so they require a minimum of human judgment. I'm not sure that's the case. The nature of the false positives is that they're generally _temporary_ aberrations, caused by the loss of synchronisation of various maintainers w.r.t submitting patches to Linus. I'd be very surprised if the number of false positives isn't fairly stable, with new ones being introduced at a similar rate to the rate at which old ones finally become correct. Might be interesting to check a few older kernels to see if this is true. Actually I might expect it to be roughly proportional to the number of separately-maintained bodies of code - so it'll grow over time, as the size of the Linux kernel grows. -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id B39B4482A for ; Fri, 20 Apr 2001 15:36:07 -0600 (MDT) Date: Fri, 20 Apr 2001 17:35:14 -0400 From: "Eric S. Raymond" To: David Woodhouse Cc: Nicolas Pitre , Tom Rini , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420173514.A21392@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010420172435.A21252@thyrsus.com> <6817.987801548@redhat.com> <20010420172435.A21252@thyrsus.com> <7043.987802140@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <7043.987802140@redhat.com>; from dwmw2@infradead.org on Fri, Apr 20, 2001 at 10:29:00PM +0100 List-ID: David Woodhouse : > I'd be very surprised if the number of false positives isn't fairly stable, > with new ones being introduced at a similar rate to the rate at which old > ones finally become correct. Even supposing that's so, a 36% rate of broken symbols is way too high. It argues that we need to do a thorough housecleaning at least once in order to get back to an acceptably low stable rate. -- Eric S. Raymond The same applies for other kinds of long-lasting low-level pain. [...] The body's response to being jabbed, pierced, and cut is to produce endorphins. [...] So here's my programme for breaking that cycle of dependency on Windows: get left arm tattooed with dragon motif, buy a crate of Jamaican Hot! Pepper Sauce, get nipples pierced. With any luck that will produce enough endorphins to make Windows completely redundant, and I can then upgrade to Linux and get on with things. -- Pieter Hintjens From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from passion.cambridge.redhat.com (dell-paw-3.cambridge.redhat.com [195.224.55.237]) by dsl2.external.hp.com (Postfix) with ESMTP id 35450482A for ; Fri, 20 Apr 2001 15:40:48 -0600 (MDT) From: David Woodhouse In-Reply-To: <20010420173514.A21392@thyrsus.com> References: <20010420173514.A21392@thyrsus.com> <20010420172435.A21252@thyrsus.com> <6817.987801548@redhat.com> <20010420172435.A21252@thyrsus.com> <7043.987802140@redhat.com> To: esr@thyrsus.com Cc: Nicolas Pitre , Tom Rini , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 22:39:24 +0100 Message-ID: <7261.987802764@redhat.com> Sender: David Woodhouse List-ID: esr@thyrsus.com said: > Even supposing that's so, a 36% rate of broken symbols is way too > high. It argues that we need to do a thorough housecleaning at least > once in order to get back to an acceptably low stable rate. Accepted. Can we let the 2.4 "angry penguin"-enforced stabilising period finish, and give the arch and subsystem maintainers a chance to finally brave the wrath of Linus and submit their patches, before we attempt do to it though? -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by dsl2.external.hp.com (Postfix) with ESMTP id 43255482A for ; Fri, 20 Apr 2001 17:07:57 -0600 (MDT) Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? To: esr@thyrsus.com Date: Fri, 20 Apr 2001 23:53:44 +0100 (BST) Cc: dwmw2@infradead.org (David Woodhouse), nico@cam.org (Nicolas Pitre), trini@kernel.crashing.org (Tom Rini), alan@lxorguk.ukuu.org.uk (Alan Cox), acahalan@cs.uml.edu (Albert D. Cahalan), willy@ldl.fc.hp.com (Matthew Wilcox), james.rich@m.cc.utah.edu (james rich), linux-kernel@vger.kernel.org (lkml), parisc-linux@parisc-linux.org In-Reply-To: <20010420173514.A21392@thyrsus.com> from "Eric S. Raymond" at Apr 20, 2001 05:35:14 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: From: Alan Cox List-ID: > Even supposing that's so, a 36% rate of broken symbols is way too high. > It argues that we need to do a thorough housecleaning at least once in > order to get back to an acceptably low stable rate. Many of your 'broken' symbols arent. We have no idea what the real amount is From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id B590D482A for ; Fri, 20 Apr 2001 18:25:27 -0600 (MDT) Date: Fri, 20 Apr 2001 20:24:53 -0400 From: "Eric S. Raymond" To: David Woodhouse Cc: Nicolas Pitre , Tom Rini , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420202453.B21392@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010420173514.A21392@thyrsus.com> <20010420172435.A21252@thyrsus.com> <6817.987801548@redhat.com> <20010420172435.A21252@thyrsus.com> <7043.987802140@redhat.com> <20010420173514.A21392@thyrsus.com> <7261.987802764@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <7261.987802764@redhat.com>; from dwmw2@infradead.org on Fri, Apr 20, 2001 at 10:39:24PM +0100 List-ID: David Woodhouse : > esr@thyrsus.com said: > > Even supposing that's so, a 36% rate of broken symbols is way too > > high. It argues that we need to do a thorough housecleaning at least > > once in order to get back to an acceptably low stable rate. > > Accepted. Can we let the 2.4 "angry penguin"-enforced stabilising period > finish, and give the arch and subsystem maintainers a chance to finally > brave the wrath of Linus and submit their patches, before we attempt do to > it though? I guess so. We don't particularly have a choice, do we? :-) -- Eric S. Raymond "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." -- George Washington, in a speech of January 7, 1790 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id D54C1482A for ; Fri, 20 Apr 2001 18:37:56 -0600 (MDT) Date: Fri, 20 Apr 2001 20:37:00 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: David Woodhouse , Nicolas Pitre , Tom Rini , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420203700.E21392@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010420173514.A21392@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Apr 20, 2001 at 11:53:44PM +0100 List-ID: Alan Cox : > > Even supposing that's so, a 36% rate of broken symbols is way too high. > > It argues that we need to do a thorough housecleaning at least once in > > order to get back to an acceptably low stable rate. > > Many of your 'broken' symbols arent. We have no idea what the real amount is If it can't be mechanically verified that the symbol has a correct reference pattern within the tree, then it's broken. That's a definition. The fact that it might become un-broken someday, by somebody's intention to merge in future code, is interesting but irrelevant to the fact that symbols broken in present time *mask bugs* in present time. I'm not being a compulsive neatnik -- that wouldn't be worth my time. What I'm trying to do is reduce the number of crevices in which bugs can hide. -- Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id B74A7482A for ; Fri, 20 Apr 2001 18:53:48 -0600 (MDT) Date: Fri, 20 Apr 2001 20:52:46 -0400 From: "Eric S. Raymond" To: Andreas Dilger Cc: Russell King , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Message-ID: <20010420205246.A22693@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010420195004.A5510@flint.arm.linux.org.uk> <200104202123.f3KLNWSm031572@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200104202123.f3KLNWSm031572@webber.adilger.int>; from adilger@turbolinux.com on Fri, Apr 20, 2001 at 03:23:32PM -0600 Subject: [parisc-linux] Proposal for better attribution structure List-ID: Andreas Dilger : > One of the issues for contacting each MAINTAINER is that this information > is out-of-line from the actual kernel tree. The other is that the > description of what a maintainer is actually controlling is somewhat > vague. I strongly agree. I first tripped over this problem when I was trying to identify the responsible parties for [Cc]onfig.in files. It's biting me again now that I'm trying to clean up the CONFIG_ space. It's one that's going to cause grief for anybody trying to do *global* work on the kernel, stuff that crosses boundaries between maintainer jurisdictions. > How about the following: > - each directory has a MAINTAINERS file which lists parties with a > vested interest in files in that directory (format is mostly the > same as current) > - subdirectories which don't have a MAINTAINERS file use the MAINTAINERS > file of the parent (or grandparent) directory > - each maintainer entry explicitly lists each file/directory that this > person is interested in, maybe "F: {file | directory} ...". > > I'm sure Eric can come up with a simple program to parse the MAINTAINER > file/tree. If the program takes a kernel-tree relative filename and > spit out the name/email of the relevant maintainer (subsystem and port > specific mailing lists should also be included), that would make the > job of finding out who to send patches to a whole lot easier. The spirit of this proposal is, IMO, excellent. I like the idea that if maintainer information for a particular piece of the hierarchy doesn't exist, you float up to the next higher level. Search always ends at the root MAINTAINERS file. And I could indeed write a program such as Andreas describes, and would be most willing to do so. I have one objection, however. I think the maintainers information should normally be inline of the file in question, so there won't be a need for an explicit F: link that could become invalid. So I think the search order should look like this: 1. Look for maintainer markup in the file itself. 2. Then look for a NAINTAINERS file in the current directory. 3. Then look upwards for MAINTAINERS files in enclosing directories. > My one gripe about the MAINTAINERS file is that it still lists Remy > Card as EXT2 maintainer, so we would probably need to do a find on > the whole kernel tree, email each address a list of files that they > "maintain" and wait until they complain, agree, or time out. Once > the database is up-to-date, it simplifies the job of keeping maintainers > (and other interested parties) in the loop. I have until 6 May at least to work on this, if there is consensus that it's a good idea. -- Eric S. Raymond Where rights secured by the Constitution are involved, there can be no rule making or legislation which would abrogate them. -- Miranda vs. Arizona, 384 US 436 p. 491 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from riker.mountain.net (smtp.mountain.net [198.77.1.35]) by dsl2.external.hp.com (Postfix) with ESMTP id 1C0FC482A for ; Fri, 20 Apr 2001 21:09:08 -0600 (MDT) Sender: tleete@dsl2.external.hp.com Message-ID: <3AE0F999.BA288768@mountain.net> Date: Fri, 20 Apr 2001 23:08:09 -0400 From: Tom Leete MIME-Version: 1.0 To: Russell King Cc: lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? References: <20010420085148.V13403@opus.bloom.county> <20010420125005.B8086@thyrsus.com> <20010420200859.B5510@flint.arm.linux.org.uk> Content-Type: text/plain; charset=us-ascii List-ID: [Cc: trimmed] Russell King wrote: > [...] > > Generally it seems like diff needs to produce one more line of context, and > most of these problems will go away. Yes, there will still be the odd > problem, so then it becomes the "how much do you crank the setting" problem. > $ diff -6 ... will give 6 lines of context. patch will understand the output without any extra help. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from puffin.external.hp.com (puffin.external.hp.com [192.25.206.4]) by dsl2.external.hp.com (Postfix) with ESMTP id 08116482A for ; Sat, 21 Apr 2001 00:54:46 -0600 (MDT) Message-Id: <200104210648.AAA01233@puffin.external.hp.com> To: "Eric S. Raymond" Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: Your message of "Fri, 20 Apr 2001 15:47:43 EDT." <20010420154743.A19618@thyrsus.com> Date: Sat, 21 Apr 2001 00:48:19 -0600 From: Grant Grundler List-ID: "Eric S. Raymond" wrote: > Here's what I have for you guys: ... > CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c > CONFIG_FUNC_SIZE: arch/parisc/kernel/sba_iommu.c > > Would you please take these out of the CONFIG_ namespace? Changing the > prefix to CONFIGURE would do nicely. As willy noted, both mine. I'll remove or rename them rename them so they aren't in the CONFIG_ name space. Probably s/CONFIG_/SBA_/ for those two. I'm going to submit a "wishlist" bug to our debian BTS (bugs.parisc-linux.org) for "Data Memory Break Trap" support. It's a damn good Hammer! :^) (GDB will probably want to use this too) I once had a working "Data Memory Break Trap" handler to catch other parts of the kernel when they corrupted the IO Pdirs. Hooks in sba_ccio.c helped mark which pages would trap and define which code was allowed to touch the page. My implementation had issues and I never bothered to re-implement as suggested by our parisc CPU god, John Marvin. CONFIG_FUNC_SIZE is just a bad choice of name (asking for trouble). One might consider this a bug that hasn't happened yet - thanks Eric! #define CONFIG_FUNC_SIZE 4096 /* SBA configuration function reg set */ > CONFIG_KWDB: arch/parisc/Makefile arch/parisc/config.in arch/parisc/defconfig > arch/parisc/kernel/entry.S arch/parisc/kernel/traps.c arch/parisc/mm/init. > c This ones actually mine too. It could be replaced with the SGI debugger CONFIG option if/when that ever gets supported. The hooks will have to be in the same place. I'm pretty sure now the HP KWBD team will never give me permission to publish KWDB sources (they've had almost a year now). I sorta almost had the damn thing working too...*sigh*. Willy should do whatever he thinks is right in this case. > CONFIG_PCI_LBA: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kerne > l/Makefile ... > Looks like these need Configure.help entries. That's mine too. We've been lazy about documentation since the getting the code working has been a higher priority. I think having them documented will be a prerequisite to merging upstream (either to Alan Cox or Linus). thanks, grant Grant Grundler parisc-linux {PCI|IOMMU|SMP} hacker +1.408.447.7253 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by dsl2.external.hp.com (Postfix) with ESMTP id DBB0B482A for ; Sat, 21 Apr 2001 02:54:04 -0600 (MDT) Received: from dyn-33.linux.theplanet.co.uk ([195.92.244.33] helo=caramon.arm.linux.org.uk) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 14qt9N-0001Md-00; Sat, 21 Apr 2001 09:53:53 +0100 Received: from raistlin.arm.linux.org.uk (IDENT:root@raistlin.arm.linux.org.uk [192.168.0.3]) by caramon.arm.linux.org.uk (8.11.0/8.11.0) with ESMTP id f3L8rmb02520; Sat, 21 Apr 2001 09:53:53 +0100 From: rmk@arm.linux.org.uk Received: (from rmk@localhost) by raistlin.arm.linux.org.uk (8.7.4/8.7.3) id JAA00811; Sat, 21 Apr 2001 09:53:48 +0100 Message-Id: <200104210853.JAA00811@raistlin.arm.linux.org.uk> Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone To: tleete@mountain.net (Tom Leete) Date: Sat, 21 Apr 2001 09:53:47 +0100 (BST) Cc: linux-kernel@vger.kernel.org (lkml), parisc-linux@parisc-linux.org In-Reply-To: <3AE0F999.BA288768@mountain.net> from "Tom Leete" at Apr 20, 2001 11:08:09 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-ID: Tom Leete writes: > $ diff -6 ... > will give 6 lines of context. patch will understand the output without any > extra help. Indeed, but I can't do that to a patch that Alan or Linus produces. -- 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: from passion.cambridge.redhat.com (dell-paw-3.cambridge.redhat.com [195.224.55.237]) by dsl2.external.hp.com (Postfix) with ESMTP id 0A883482A for ; Sat, 21 Apr 2001 06:37:10 -0600 (MDT) From: David Woodhouse In-Reply-To: <20010420203700.E21392@thyrsus.com> References: <20010420203700.E21392@thyrsus.com> <20010420173514.A21392@thyrsus.com> To: esr@thyrsus.com Cc: Alan Cox , Nicolas Pitre , Tom Rini , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Apr 2001 13:32:13 +0100 Message-ID: <1164.987856333@redhat.com> Sender: David Woodhouse List-ID: esr@thyrsus.com said: > If it can't be mechanically verified that the symbol has a correct > reference pattern within the tree, then it's broken. That's a > definition. Here's an alternative definition: If the symbol has the letters 'F', 'I', 'S' and 'H' in it, in any order, then it's broken. That's also a definition. It's not a particularly useful one, but neither was yours. /me looks for a way to equate the original definition with the halting problem :) -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (snark.tuxedo.org [207.106.50.26]) by dsl2.external.hp.com (Postfix) with ESMTP id C6202482A for ; Sat, 21 Apr 2001 08:51:24 -0600 (MDT) Date: Sat, 21 Apr 2001 10:52:00 -0400 From: "Eric S. Raymond" To: Grant Grundler Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010421105200.C26142@thyrsus.com> Reply-To: esr@thyrsus.com References: <20010420154743.A19618@thyrsus.com> <200104210648.AAA01233@puffin.external.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200104210648.AAA01233@puffin.external.hp.com>; from grundler@puffin.external.hp.com on Sat, Apr 21, 2001 at 12:48:19AM -0600 List-ID: Grant Grundler : > One might consider this a bug that hasn't happened yet - thanks Eric! Thank you very much for your cooperation. This is the third real problem that the CONFIG_ namespace audit has turned up, and a good example of the sort of thing I have been hoping to accomplish with it. -- 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: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by dsl2.external.hp.com (Postfix) with ESMTP id A318B482A for ; Sat, 21 Apr 2001 17:41:14 -0600 (MDT) Sender: Jes.Sorensen@cern.ch To: esr@thyrsus.com Cc: Alan Cox , David Woodhouse , Nicolas Pitre , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? References: <20010420173514.A21392@thyrsus.com> <20010420203700.E21392@thyrsus.com> From: Jes Sorensen Date: 22 Apr 2001 01:39:25 +0200 In-Reply-To: "Eric S. Raymond"'s message of "Fri, 20 Apr 2001 20:37:00 -0400" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-ID: >>>>> "Eric" == Eric S Raymond writes: Eric> Alan Cox : >> Many of your 'broken' symbols arent. We have no idea what the real >> amount is Eric> If it can't be mechanically verified that the symbol has a Eric> correct reference pattern within the tree, then it's broken. Eric> That's a definition. It's a definition but not necessarily the best one to follow. Eric> The fact that it might become un-broken someday, by somebody's Eric> intention to merge in future code, is interesting but irrelevant Eric> to the fact that symbols broken in present time *mask bugs* in Eric> present time. Symbols that are not referenced at all by the code does not hide any bugs. They might make it take longer time for people to configure their kernel but thats about it. This does not mean that obsolete symbols should not be removed, however running around telling people to remove symbols that they might be using in their tree does cause unnecessary work for the people who are writing the code. Jes 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, 19 Apr 2001 22:37:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 19 Apr 2001 22:36:52 -0400 Received: from atlrel2.hp.com ([156.153.255.202]:38348 "HELO atlrel2.hp.com") by vger.kernel.org with SMTP id ; Thu, 19 Apr 2001 22:36:40 -0400 Date: Thu, 19 Apr 2001 20:36:39 -0600 To: esr@thyrsus.com Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010419203639.H4217@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i From: willy@ldl.fc.hp.com (Matthew Wilcox) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote: > Remove dead CONFIG_BINFMT_JAVA symbol. Please don't do this, it just makes merging our patches with Linus harder. This has already been done in our tree since Feb 1. In fact, please don't touch anything in the tree which is PA specific; we have a large arch update pending. http://puffin.external.hp.com/cvs/linux/arch/parisc/config.in?log=y shows the current state of our config.in, if you're curious. If you have any changes you want to make, don't hesitate to coordinate with us by mailing parisc-linux@parisc-linux.org. 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, 19 Apr 2001 23:00:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 19 Apr 2001 23:00:34 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:48395 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Thu, 19 Apr 2001 23:00:25 -0400 Date: Thu, 19 Apr 2001 23:00:09 -0400 From: "Eric S. Raymond" To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010419230009.A32500@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Matthew Wilcox , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010419203639.H4217@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010419203639.H4217@zumpano.fc.hp.com>; from willy@ldl.fc.hp.com on Thu, Apr 19, 2001 at 08:36:39PM -0600 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 Matthew Wilcox : > On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote: > > Remove dead CONFIG_BINFMT_JAVA symbol. > > Please don't do this, it just makes merging our patches with Linus harder. Bother. I've now heard "don't touch that tree!" from you and the ARM folks. I'm trying to be a good neighbor, here, but there is some cleanup I want to do that crosses port boundaries. (None of this is CML2, BTW; I'm now addressing problems that are common to CML1 as well.) What is the right procedure for doing changes like this? Is "don't touch that tree" a permanent condition, or am I going to get a chance to clean up the global CONFIG_ namespace after your next merge-down? Could I ask you to audit your tree and change the prefix on any CONFIG_ symbols that are private over there? This would make life easier for my auditing tools (kxref and Stephen Cole's ach script). That's the main thing I'm after right now -- I want to cut down on the false positives in my orphaned-symbol reports so that the actual bugs will stand out. -- Eric S. Raymond "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, Historical Review of Pennsylvania, 1759. 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, 19 Apr 2001 23:18:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 19 Apr 2001 23:17:54 -0400 Received: from atlrel1.hp.com ([156.153.255.210]:10480 "HELO atlrel1.hp.com") by vger.kernel.org with SMTP id ; Thu, 19 Apr 2001 23:17:51 -0400 Date: Thu, 19 Apr 2001 21:17:49 -0600 To: "Eric S. Raymond" , Matthew Wilcox , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010419211749.I4217@zumpano.fc.hp.com> In-Reply-To: <20010419203639.H4217@zumpano.fc.hp.com> <20010419230009.A32500@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: <20010419230009.A32500@thyrsus.com>; from esr@thyrsus.com on Thu, Apr 19, 2001 at 11:00:09PM -0400 From: willy@ldl.fc.hp.com (Matthew Wilcox) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote: > What is the right procedure for doing changes like this? Is "don't > touch that tree" a permanent condition, or am I going to get a chance > to clean up the global CONFIG_ namespace after your next merge-down? Our current status is that we've got a patch with Alan that's been sitting in his tree for a while (things got trickier than he expected and he hasn't been able to merge that upstream to Linus yet). Meanwhile we've carried on development as normal. So even after the patches in Alan's tree land, we've still got a fair hunk of changes to go in. My preference would be for you to fetch our tree cvs -d :pserver:anonymous@puffin.external.hp.com:/home/cvs/parisc login [no password] cvs -d :pserver:anonymous@puffin.external.hp.com:/home/cvs/parisc co linux and submit patches to us, which will get to Linus in the fullness of time. I'm aware this might not be terribly satisfactory for you, but we're doing our best not to lose our way amid the churn of development right now and having patches which haven't followed a progression through us makes that significantly harder. > Could I ask you to audit your tree and change the prefix on any > CONFIG_ symbols that are private over there? This would make life > easier for my auditing tools (kxref and Stephen Cole's ach script). I don't think we have any of those. We certainly have symbols which are defined for symmetry and may not actually be used yet (CONFIG_PA11 might not be, perhaps). But that's what happens when you're developing software :-) 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, 20 Apr 2001 00:09:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 00:09:35 -0400 Received: from pipt.oz.cc.utah.edu ([155.99.2.7]:61166 "EHLO pipt.oz.cc.utah.edu") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 00:09:23 -0400 Date: Thu, 19 Apr 2001 22:07:22 -0600 (MDT) From: james rich To: Matthew Wilcox cc: "Eric S. Raymond" , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: <20010419211749.I4217@zumpano.fc.hp.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, 19 Apr 2001, Matthew Wilcox wrote: > On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote: > > What is the right procedure for doing changes like this? Is "don't > > touch that tree" a permanent condition, or am I going to get a chance > > to clean up the global CONFIG_ namespace after your next merge-down? > [snip] > My preference would be for you to fetch our tree > and submit patches to us, which will get to Linus in the fullness of time. Truly this is not meant to be negative - don't take it as such. Doesn't this seem a little like the problems occurring with lvm right now? A separate tree maintained with the maintainers not wanting others submitting patches that conflict with their particular tree? It seems that any project should be able to submit any patch against The One True Tree: Linus' tree. James Rich james.rich@m.cc.utah.edu 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, 20 Apr 2001 00:19:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 00:19:25 -0400 Received: from atlrel2.hp.com ([156.153.255.202]:39111 "HELO atlrel2.hp.com") by vger.kernel.org with SMTP id ; Fri, 20 Apr 2001 00:19:17 -0400 Date: Thu, 19 Apr 2001 22:19:16 -0600 To: james rich Cc: Matthew Wilcox , "Eric S. Raymond" , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010419221916.K4217@zumpano.fc.hp.com> In-Reply-To: <20010419211749.I4217@zumpano.fc.hp.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 james.rich@m.cc.utah.edu on Thu, Apr 19, 2001 at 10:07:22PM -0600 From: willy@ldl.fc.hp.com (Matthew Wilcox) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote: > Doesn't this seem a little like the problems occurring with lvm right now? > A separate tree maintained with the maintainers not wanting others > submitting patches that conflict with their particular tree? It seems > that any project should be able to submit any patch against The One True > Tree: Linus' tree. every single architecture has their own development tree. the pa project has not been running as long as the other ports, and has a large amount of development going on. i count 28 commits for april (so far), 75 commits for march, 187 for february and 112 for january (to the kernel tree, other parts of the port also have commit messages). linus would go insane if we sent him every single one of those patches individually. and we'd go insane trying to keep up with what he'd taken and what he'd dropped. until you've actually tried doing this, please don't attempt to criticise. 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, 20 Apr 2001 00:53:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 00:53:44 -0400 Received: from saturn.cs.uml.edu ([129.63.8.2]:38922 "EHLO saturn.cs.uml.edu") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 00:53:35 -0400 From: "Albert D. Cahalan" Message-Id: <200104200452.f3K4q3X07411@saturn.cs.uml.edu> Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? To: willy@ldl.fc.hp.com (Matthew Wilcox) Date: Fri, 20 Apr 2001 00:52:03 -0400 (EDT) Cc: james.rich@m.cc.utah.edu (james rich), willy@ldl.fc.hp.com (Matthew Wilcox), esr@thyrsus.com (Eric S. Raymond), linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010419221916.K4217@zumpano.fc.hp.com> from "Matthew Wilcox" at Apr 19, 2001 10:19:16 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 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 Matthew Wilcox writes: > On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote: >> Doesn't this seem a little like the problems occurring with lvm right now? >> A separate tree maintained with the maintainers not wanting others >> submitting patches that conflict with their particular tree? It seems >> that any project should be able to submit any patch against The One True >> Tree: Linus' tree. > > every single architecture has their own development tree. This sucks for users of that architecture. Also, though not applicable to PA-RISC, it sucks for sub-architecture porters. (by sub-architecture I mean: Mac, PReP, PowerCore, BeBox, etc.) It's hard enough deciding between Linus and Alan. I'm not at all happy trying to pick through obscure CVS and BitKeeper trees that might not be up-to-data with the latest mainstream bug fixes. > the pa project > has not been running as long as the other ports, and has a large amount of > development going on. i count 28 commits for april (so far), 75 commits > for march, 187 for february and 112 for january (to the kernel tree, other > parts of the port also have commit messages). linus would go insane if > we sent him every single one of those patches individually. and we'd > go insane trying to keep up with what he'd taken and what he'd dropped. > > until you've actually tried doing this, please don't attempt to criticise. Have _you_ tried? If I recall correctly, Linus spoke out against the PowerPC people doing the exact same thing. So unless you get told to quit annoying him with patches, sending them is the safe bet. Well here we go. It's about IrDA though, not PowerPC. Read it! http://lwn.net/2000/1109/a/lt-IrDA.php3 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, 20 Apr 2001 01:20:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 01:19:57 -0400 Received: from garrincha.netbank.com.br ([200.203.199.88]:55814 "HELO netbank.com.br") by vger.kernel.org with SMTP id ; Fri, 20 Apr 2001 01:19:52 -0400 Date: Fri, 20 Apr 2001 02:17:42 -0300 (BRST) From: Rik van Riel To: "Albert D. Cahalan" Cc: Matthew Wilcox , james rich , "Eric S. Raymond" , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: <200104200452.f3K4q3X07411@saturn.cs.uml.edu> 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, 20 Apr 2001, Albert D. Cahalan wrote: > This sucks for users of that architecture. Also, though not > applicable to PA-RISC, it sucks for sub-architecture porters. > (by sub-architecture I mean: Mac, PReP, PowerCore, BeBox, etc.) As you said it so eloquently a few paragraphs down: "send patches!" cheers, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ 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, 20 Apr 2001 04:24:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 04:24:42 -0400 Received: from t2.redhat.com ([199.183.24.243]:5620 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 04:24:31 -0400 X-Mailer: exmh version 2.3 01/15/2001 with nmh-1.0.4 From: David Woodhouse X-Accept-Language: en_GB In-Reply-To: In-Reply-To: To: james rich Cc: Matthew Wilcox , "Eric S. Raymond" , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 09:19:53 +0100 Message-ID: <14608.987754793@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org james.rich@m.cc.utah.edu said: > Doesn't this seem a little like the problems occurring with lvm right > now? A separate tree maintained with the maintainers not wanting > others submitting patches that conflict with their particular tree? > It seems that any project should be able to submit any patch against > The One True Tree: Linus' tree. Of course they can. Linus does apply them too. People are asking nicely that ESR not do so in this case, because merges are being planned. The contents of drivers/mtd/ are in the same situation. For some reason, I felt it inappropriate to give every patch at every stage of development to Linus for inclusion in the 2.4.0-test and 2.4.[123] kernels. Now I'm vaguely happy with it all and it's stable, I'm working on cleaning up some of the cosmetics and breaking it up into digestible patches. Doing primary development in CVS seems to work OK for me, and allows me to continue development without destabilising the One True Tree. During such times, it's useful to have a branch for the code which is in the One True Tree, so urgent fixes can be merged, and the diff against the One True Tree after each release has something to diff against to catch patches where people didn't even bother to Cc the maintainer. I believe people were _told_ to hold off until 2.4.5-ish, or when the tree became stable. Violent imagery was used to reinforce this instruction. That being the case, how about holding the config changes back until after everyone else who's been waiting has merged their pending changes? -- 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 ; Fri, 20 Apr 2001 12:06:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 12:06:42 -0400 Received: from panic.ohr.gatech.edu ([130.207.47.194]:2024 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 20 Apr 2001 12:06:26 -0400 Message-ID: <3AE05E7C.F9C76ED2@mandrakesoft.com> Date: Fri, 20 Apr 2001 12:06:20 -0400 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-pre5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tom Rini Cc: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: <20010420101951.A6011@thyrsus.com> <20010420105934.A6668@thyrsus.com> <20010420085148.V13403@opus.bloom.county> 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 Tom Rini wrote: > Which does boil down to having to work with trees other than Linus or > Alans. Remember, the official tree is not always the up-to-date tree, > or in the case of other arches, the most relevant tree. Yep. You could even look at Linus as simply the x86 port maintainer :) Except for alpha and x86, AFAIK, most people wind up going through arch-specific channels to get their kernels... -- Jeff Garzik | The difference between America and England is that Building 1024 | the English think 100 miles is a long distance and MandrakeSoft | the Americans think 100 years is a long time. | (random fortune) 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, 20 Apr 2001 12:26:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 12:26:35 -0400 Received: from panic.ohr.gatech.edu ([130.207.47.194]:8683 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Fri, 20 Apr 2001 12:26:30 -0400 Message-ID: <3AE0632E.61B20C0A@mandrakesoft.com> Date: Fri, 20 Apr 2001 12:26:22 -0400 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-pre5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bob McElrath Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: <20010420101951.A6011@thyrsus.com> <20010420105934.A6668@thyrsus.com> <20010420085148.V13403@opus.bloom.county> <3AE05E7C.F9C76ED2@mandrakesoft.com> <20010420111512.H22687@draal.physics.wisc.edu> 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 Bob McElrath wrote: > > Jeff Garzik [jgarzik@mandrakesoft.com] wrote: > > Tom Rini wrote: > > > Which does boil down to having to work with trees other than Linus or > > > Alans. Remember, the official tree is not always the up-to-date tree, > > > or in the case of other arches, the most relevant tree. > > > > Yep. You could even look at Linus as simply the x86 port maintainer :) > > > > Except for alpha and x86, AFAIK, most people wind up going through > > arch-specific channels to get their kernels... > > This may be a dumb question, but is there some place where the arch > maintainers are listed? Where the arch-specific trees are kept? Where > would I go to get the latest set of relevant patches for alpha? As I noted in the e-mail to which you replied, there is no separate alpha tree nor arch-specific channel for alpha kernels. Generally fixes to the Alpha tree appear quickly and get merged quickly, and the tree stays in sync quite well. Watch linux-kernel or Alan Cox's patchkit for Alpha fixes that may be in transmit to Linus. There are of course RedHat's alpha distro, and various mailing lists on http://www.alphalinux.org/ -- Jeff Garzik | The difference between America and England is that Building 1024 | the English think 100 miles is a long distance and MandrakeSoft | the Americans think 100 years is a long time. | (random fortune) 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, 20 Apr 2001 12:36:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 12:36:47 -0400 Received: from modemcable084.137-200-24.mtl.mc.videotron.ca ([24.200.137.84]:39920 "EHLO xanadu.home") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 12:36:33 -0400 Date: Fri, 20 Apr 2001 12:35:12 -0400 (EDT) From: Nicolas Pitre X-X-Sender: To: Tom Rini cc: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: <20010420085148.V13403@opus.bloom.county> 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, 20 Apr 2001, Tom Rini wrote: > On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > > Alan Cox : > > > > well, though. One is the kind I'm bumping into right now, where > > > > somebody legitimately needs to make small (almost trivial) changes > > > > scattered all through the tree. > > > > > > Yep. But such changes are rare. Or should be. > > > > Knowing that doesn't help me much, since I'm trying to fix up a global > > namespace that touches everybody :-(. > > Which does boil down to having to work with trees other than Linus or > Alans. Remember, the official tree is not always the up-to-date tree, > or in the case of other arches, the most relevant tree. But if you send > something off to a maintainer, there's a good chance (if they're still active) > they'll do what you ask, and it'll get to Linus/Alan the next time they sync. > As long as the problem gets fixed, it shouldn't be as important if it's fixed > in everyones tree right now, or in a release or two. If it's some sort of > huge bug it just might get fixed sooner. Guys, There is kind of a ridiculous situation here where people want to withhold their own changes in their own trees for all good reasons until it is mature and stable enough to be fed upstream in the appropriate way, while insisting for Linus' tree to remain incomplete and inconsistent. And we're not talking about deep architectural changes here -- only about configure symbols and help text. Why not having everybody's tree consistent with themselves and have whatever CONFIGURE_* symbols and help text be merged along with the very code it refers to? It's worthless to have config symbols be merged into Linus' or Alan's tree if the code isn't there (yet). It simply makes no sense. This might shift some of the namespace consistency work to architecture maintainers (which is a good thing IMHO) and establish the basis for yet a more sanitized kernel.org tree at all times for before and after any further patches are merged. I'm myself maintainer of a subarchitecture and removing currently unreferenced SA1100 config symbols from the official Linux tree would probably give me a one-time effort to bring them back in my tree but this is certainly for a saner code/namespace distribution in general. Why should the symbols I maintain remain there if I'm not ready yet to sync up the code they refer to? Hey this is only CONFIG_ symbols after all. If they get removed now, they will only reappear _with_ the code they refer to eventually when it'll get merged. Nicolas 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, 20 Apr 2001 13:47:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 13:47:48 -0400 Received: from mnh-1-16.mv.com ([207.22.10.48]:62470 "EHLO ccure.karaya.com") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 13:47:35 -0400 Message-Id: <200104201900.OAA03252@ccure.karaya.com> X-Mailer: exmh version 2.0.2 To: Matthew Wilcox cc: Bob McElrath Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: Your message of "Fri, 20 Apr 2001 17:21:26 +0100." <20010420172126.C18464@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 14:00:00 -0500 From: Jeff Dike Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org matthew@wil.cx said: > http://www.kernel.org/ has a list of architecture websites. Also the > CREDITS / MAINTAINERS files tend to list the people who are involved. Except it's restricted to processor ports, which would leave you not knowing about UML. 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, 20 Apr 2001 14:50:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 14:49:56 -0400 Received: from modemcable084.137-200-24.mtl.mc.videotron.ca ([24.200.137.84]:38641 "EHLO xanadu.home") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 14:49:48 -0400 Date: Fri, 20 Apr 2001 14:48:18 -0400 (EDT) From: Nicolas Pitre X-X-Sender: To: Tom Rini cc: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: <20010420112042.Z13403@opus.bloom.county> 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, 20 Apr 2001, Tom Rini wrote: > On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: > > > Why not having everybody's tree consistent with themselves and have whatever > > CONFIGURE_* symbols and help text be merged along with the very code it > > refers to? It's worthless to have config symbols be merged into Linus' or > > Alan's tree if the code isn't there (yet). It simply makes no sense. > > Well, this depends a lot on a) The project to be merged (arch, mtd, whatever) > and b) how far something has gotten in being merged someplace else, and of > course c) the maintainer(s). Whatever the exact case, and in general, it > should be handled via the maintainer. Why? They maintain the code. Therefore it's the maintainer's job to submit coherent patches and accept to see inconsistent CONFIG_* references be removed from the official tree until further patch submission is due. It's only a question of discipline. Otherwise how can you distinguish between dead wood which must be removed and potentially valid symbols referring to code existing only in a remote tree? Nicolas 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, 20 Apr 2001 14:55:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 14:55:04 -0400 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:25101 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 14:54:50 -0400 Date: Fri, 20 Apr 2001 19:50:04 +0100 From: Russell King To: "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420195004.A5510@flint.arm.linux.org.uk> In-Reply-To: <20010420101951.A6011@thyrsus.com> <20010420105934.A6668@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: <20010420105934.A6668@thyrsus.com>; from esr@thyrsus.com on Fri, Apr 20, 2001 at 10:59:34AM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > All right then. I'm going to send you a bunch of dead-symbol cleanup > patches. I'll try to stay in the mainline code and out of the port > trees. Would you please do me the kindness of telling me which ones > can go in and which ones you think have to go through maintainers? >>From my point of view, I'd be happy if stuff that touched the ARM tree directly was sent separately from the other architectures, and actually was copied to me. I'm sure that the other architecture maintainers feel the same way, but I'll let them comment separately. Why? Well: - Firstly, I can apply your patch directly to my tree without having to bother about the effects in the other architecture trees. (hence when I resync with Linus or Alan, I don't have to go around fixing up rejects in other architecture trees). - Secondly, its very easy to miss stuff in the lkml hunk of email each day when you have less than 4 hours to read it and think about it. (note that architecture maintainers have to read mail from their side which may not be on lkml, think about that, think about bug fixes, possible impacts of fixes on other machines, etc etc). Therefore, copying their email address registered in the MAINTAINER file means that they should not overlook your patch. - I know that Alan does take lots of patches off lkml, but I'm not sure what his criterion is for selecting them. In the case which started this thread off, I'm always worried that your cleanup patch would make it in, and then cause me problems later on. -- 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 ; Fri, 20 Apr 2001 15:48:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 15:48:18 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:14865 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 15:48:02 -0400 Date: Fri, 20 Apr 2001 15:47:43 -0400 From: "Eric S. Raymond" To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420154743.A19618@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Matthew Wilcox , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010419203639.H4217@zumpano.fc.hp.com> <20010419230009.A32500@thyrsus.com> <20010419211749.I4217@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010419211749.I4217@zumpano.fc.hp.com>; from willy@ldl.fc.hp.com on Thu, Apr 19, 2001 at 09:17:49PM -0600 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 Matthew Wilcox : > > Could I ask you to audit your tree and change the prefix on any > > CONFIG_ symbols that are private over there? This would make life > > easier for my auditing tools (kxref and Stephen Cole's ach script). > > I don't think we have any of those. We certainly have symbols which are > defined for symmetry and may not actually be used yet (CONFIG_PA11 might not > be, perhaps). But that's what happens when you're developing software :-) Here's what I have for you guys: CONFIG_BINFMT_JAVA: arch/parisc/config.in arch/parisc/defconfig arch/cris/config.in arch/cris/defconfig You've already gotten rid of that one. CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig Not used in code anywhere. Can you get rid of this one? CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c CONFIG_FUNC_SIZE: arch/parisc/kernel/sba_iommu.c Would you please take these out of the CONFIG_ namespace? Changing the prefix to CONFIGURE would do nicely. CONFIG_GENRTC: arch/parisc/defconfig This is a typo for GEN_RTC. Please fix it or get rid of it. CONFIG_HIL: arch/parisc/defconfig Looks like an orphan. Can you get rid of it? CONFIG_GSC: arch/parisc/config.in arch/parisc/defconfig CONFIG_GSC_DINO: arch/parisc/config.in arch/parisc/defconfig CONFIG_GSC_LASI: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/led.c CONFIG_GSC_PS2: arch/parisc/config.in arch/parisc/defconfig CONFIG_IODC_CONSOLE: arch/parisc/config.in arch/parisc/kernel/setup.c CONFIG_IOMMU_CCIO: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile CONFIG_IOMMU_SBA: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile CONFIG_IOSAPIC: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile CONFIG_KWDB: arch/parisc/Makefile arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/entry.S arch/parisc/kernel/traps.c arch/parisc/mm/init.c CONFIG_LASI_82596: arch/parisc/config.in arch/parisc/defconfig CONFIG_PARPORT_GSC: drivers/parport/Makefile arch/parisc/config.in arch/parisc/defconfig CONFIG_PCI_LBA: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile CONFIG_SCSI_LASI: arch/parisc/config.in arch/parisc/defconfig CONFIG_SCSI_ZALON: arch/parisc/config.in arch/parisc/defconfig CONFIG_STI_CONSOLE: arch/parisc/Makefile arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/setup.c arch/parisc/mm/init.c Looks like these need Configure.help entries. CONFIG_SERIAL_GSC: drivers/char/serial.c arch/parisc/defconfig That reference pattern looks kind of weird. Is this a bug? If you could clean these up, that's everything I need from the parisc tree. -- 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 ; Fri, 20 Apr 2001 16:00:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 16:00:28 -0400 Received: from atlrel1.hp.com ([156.153.255.210]:44792 "HELO atlrel1.hp.com") by vger.kernel.org with SMTP id ; Fri, 20 Apr 2001 16:00:18 -0400 Date: Fri, 20 Apr 2001 14:00:03 -0600 To: "Eric S. Raymond" , Matthew Wilcox , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420140003.M4217@zumpano.fc.hp.com> In-Reply-To: <20010419203639.H4217@zumpano.fc.hp.com> <20010419230009.A32500@thyrsus.com> <20010419211749.I4217@zumpano.fc.hp.com> <20010420154743.A19618@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: <20010420154743.A19618@thyrsus.com>; from esr@thyrsus.com on Fri, Apr 20, 2001 at 03:47:43PM -0400 From: willy@ldl.fc.hp.com (Matthew Wilcox) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 20, 2001 at 03:47:43PM -0400, Eric S. Raymond wrote: > CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig > > Not used in code anywhere. Can you get rid of this one? Code not merged yet. > CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c > CONFIG_FUNC_SIZE: arch/parisc/kernel/sba_iommu.c > > Would you please take these out of the CONFIG_ namespace? Changing the > prefix to CONFIGURE would do nicely. Grant? This is your code. > CONFIG_GENRTC: arch/parisc/defconfig > > This is a typo for GEN_RTC. Please fix it or get rid of it. in our tree it's in drivers/char/Makefile: obj-$(CONFIG_GENRTC) += genrtc.o this code was written by Sam Creasey as part of the sun3 port, and he schlepped it into our tree too. we have no GEN_RTC in our tree. > CONFIG_HIL: arch/parisc/defconfig > > Looks like an orphan. Can you get rid of it? code not yet merged. > CONFIG_SERIAL_GSC: drivers/char/serial.c arch/parisc/defconfig > > That reference pattern looks kind of weird. Is this a bug? it's old and needs to die properly. i haven't had time to fix that 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 ; Fri, 20 Apr 2001 16:13:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 16:13:38 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:23313 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 16:13:30 -0400 Date: Fri, 20 Apr 2001 16:13:04 -0400 From: "Eric S. Raymond" To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? Message-ID: <20010420161304.A19954@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Matthew Wilcox , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010419203639.H4217@zumpano.fc.hp.com> <20010419230009.A32500@thyrsus.com> <20010419211749.I4217@zumpano.fc.hp.com> <20010420154743.A19618@thyrsus.com> <20010420140003.M4217@zumpano.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010420140003.M4217@zumpano.fc.hp.com>; from willy@ldl.fc.hp.com on Fri, Apr 20, 2001 at 02:00:03PM -0600 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 Matthew Wilcox : > Code not merged yet. : > it's old and needs to die properly. i haven't had time to fix that yet. Thanks for the information. Actually the parisc tree is one of the ones that leaks the fewest of these symbols... -- Eric S. Raymond Ideology, politics and journalism, which luxuriate in failure, are impotent in the face of hope and joy. -- P. J. O'Rourke 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, 20 Apr 2001 16:43:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 16:42:57 -0400 Received: from mnh-1-15.mv.com ([207.22.10.47]:23815 "EHLO ccure.karaya.com") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 16:42:38 -0400 Message-Id: <200104202155.QAA04046@ccure.karaya.com> X-Mailer: exmh version 2.0.2 To: Matthew Wilcox Cc: Bob McElrath , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: Your message of "Fri, 20 Apr 2001 19:47:02 +0100." <20010420194702.E18464@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 16:55:18 -0500 From: Jeff Dike Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org matthew@wil.cx said: > Have you tried mailing webmaster@kernel.org and asking to be added? Yes. jes@linuxcare.com said: > I'd be highly surprised if they said no to adding UML to the list if > you mailed them a request to update the page. Well, be surprised then. The reply from hpa was that that list was for processor ports. He did say that there might at some point in the future be a separate list (off the main page) of other things. 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, 20 Apr 2001 16:55:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 16:54:57 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:26376 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 16:54:46 -0400 Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? To: esr@thyrsus.com Date: Fri, 20 Apr 2001 21:55:14 +0100 (BST) Cc: willy@ldl.fc.hp.com (Matthew Wilcox), linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010420154743.A19618@thyrsus.com> from "Eric S. Raymond" at Apr 20, 2001 03:47:43 PM X-Mailer: ELM [version 2.5 PL1] 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 > CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig > Not used in code anywhere. Can you get rid of this one? Its used in the parisc tree as are most of the others you see. You probably want to simply skip processing arch/parisc 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, 20 Apr 2001 17:24:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 17:24:13 -0400 Received: from t2.redhat.com ([199.183.24.243]:34032 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 17:24:05 -0400 X-Mailer: exmh version 2.3 01/15/2001 with nmh-1.0.4 From: David Woodhouse X-Accept-Language: en_GB In-Reply-To: In-Reply-To: To: Nicolas Pitre Cc: Tom Rini , "Eric S. Raymond" , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 22:19:08 +0100 Message-ID: <6817.987801548@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org nico@cam.org said: > Therefore it's the maintainer's job to submit coherent patches and > accept to see inconsistent CONFIG_* references be removed from the > official tree until further patch submission is due. Maybe. But you tend to include the latest MTD code in your tree, for example, and hence the defconfigs have the new options in. Is it really worth your time to produce separate defconfigs without it before feeding your changes upstream? > Otherwise how can you distinguish between dead wood which must be > removed and potentially valid symbols referring to code existing only > in a remote tree? By periodically publishing a list of the potentially-obsolete symbols as ESR has done, and _not_ removing the ones which people speak up about. It's not as if this is something which needs to be done more than about once a year. -- 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 ; Fri, 20 Apr 2001 17:31:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 17:30:42 -0400 Received: from t2.redhat.com ([199.183.24.243]:46320 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 17:30:33 -0400 X-Mailer: exmh version 2.3 01/15/2001 with nmh-1.0.4 From: David Woodhouse X-Accept-Language: en_GB In-Reply-To: <20010420172435.A21252@thyrsus.com> In-Reply-To: <20010420172435.A21252@thyrsus.com> <6817.987801548@redhat.com> To: esr@thyrsus.com Cc: Nicolas Pitre , Tom Rini , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 22:29:00 +0100 Message-ID: <7043.987802140@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org esr@thyrsus.com said: > Not good enough. In a year, the pile of false positives would get > high enough to make it too hard to spot real bugs like the Aironet > mismatch. The whole point of the cleanup is to be able to mechanize > the consistency checks so they require a minimum of human judgment. I'm not sure that's the case. The nature of the false positives is that they're generally _temporary_ aberrations, caused by the loss of synchronisation of various maintainers w.r.t submitting patches to Linus. I'd be very surprised if the number of false positives isn't fairly stable, with new ones being introduced at a similar rate to the rate at which old ones finally become correct. Might be interesting to check a few older kernels to see if this is true. Actually I might expect it to be roughly proportional to the number of separately-maintained bodies of code - so it'll grow over time, as the size of the Linux kernel grows. -- 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 ; Fri, 20 Apr 2001 17:41:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 17:40:54 -0400 Received: from t2.redhat.com ([199.183.24.243]:61680 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 17:40:47 -0400 X-Mailer: exmh version 2.3 01/15/2001 with nmh-1.0.4 From: David Woodhouse X-Accept-Language: en_GB In-Reply-To: <20010420173514.A21392@thyrsus.com> In-Reply-To: <20010420173514.A21392@thyrsus.com> <20010420172435.A21252@thyrsus.com> <6817.987801548@redhat.com> <20010420172435.A21252@thyrsus.com> <7043.987802140@redhat.com> To: esr@thyrsus.com Cc: Nicolas Pitre , Tom Rini , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Apr 2001 22:39:24 +0100 Message-ID: <7261.987802764@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org esr@thyrsus.com said: > Even supposing that's so, a 36% rate of broken symbols is way too > high. It argues that we need to do a thorough housecleaning at least > once in order to get back to an acceptably low stable rate. Accepted. Can we let the 2.4 "angry penguin"-enforced stabilising period finish, and give the arch and subsystem maintainers a chance to finally brave the wrath of Linus and submit their patches, before we attempt do to it though? -- 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 ; Fri, 20 Apr 2001 20:54:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 20:53:56 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:11026 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 20:53:47 -0400 Date: Fri, 20 Apr 2001 20:52:46 -0400 From: "Eric S. Raymond" To: Andreas Dilger Cc: Russell King , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org Subject: Proposal for better attribution structure Message-ID: <20010420205246.A22693@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Andreas Dilger , Russell King , Alan Cox , "Albert D. Cahalan" , Matthew Wilcox , james rich , linux-kernel@vger.kernel.org, parisc-linux@parisc-linux.org In-Reply-To: <20010420195004.A5510@flint.arm.linux.org.uk> <200104202123.f3KLNWSm031572@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104202123.f3KLNWSm031572@webber.adilger.int>; from adilger@turbolinux.com on Fri, Apr 20, 2001 at 03:23:32PM -0600 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 Andreas Dilger : > One of the issues for contacting each MAINTAINER is that this information > is out-of-line from the actual kernel tree. The other is that the > description of what a maintainer is actually controlling is somewhat > vague. I strongly agree. I first tripped over this problem when I was trying to identify the responsible parties for [Cc]onfig.in files. It's biting me again now that I'm trying to clean up the CONFIG_ space. It's one that's going to cause grief for anybody trying to do *global* work on the kernel, stuff that crosses boundaries between maintainer jurisdictions. > How about the following: > - each directory has a MAINTAINERS file which lists parties with a > vested interest in files in that directory (format is mostly the > same as current) > - subdirectories which don't have a MAINTAINERS file use the MAINTAINERS > file of the parent (or grandparent) directory > - each maintainer entry explicitly lists each file/directory that this > person is interested in, maybe "F: {file | directory} ...". > > I'm sure Eric can come up with a simple program to parse the MAINTAINER > file/tree. If the program takes a kernel-tree relative filename and > spit out the name/email of the relevant maintainer (subsystem and port > specific mailing lists should also be included), that would make the > job of finding out who to send patches to a whole lot easier. The spirit of this proposal is, IMO, excellent. I like the idea that if maintainer information for a particular piece of the hierarchy doesn't exist, you float up to the next higher level. Search always ends at the root MAINTAINERS file. And I could indeed write a program such as Andreas describes, and would be most willing to do so. I have one objection, however. I think the maintainers information should normally be inline of the file in question, so there won't be a need for an explicit F: link that could become invalid. So I think the search order should look like this: 1. Look for maintainer markup in the file itself. 2. Then look for a NAINTAINERS file in the current directory. 3. Then look upwards for MAINTAINERS files in enclosing directories. > My one gripe about the MAINTAINERS file is that it still lists Remy > Card as EXT2 maintainer, so we would probably need to do a find on > the whole kernel tree, email each address a list of files that they > "maintain" and wait until they complain, agree, or time out. Once > the database is up-to-date, it simplifies the job of keeping maintainers > (and other interested parties) in the loop. I have until 6 May at least to work on this, if there is consensus that it's a good idea. -- Eric S. Raymond Where rights secured by the Constitution are involved, there can be no rule making or legislation which would abrogate them. -- Miranda vs. Arizona, 384 US 436 p. 491 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, 20 Apr 2001 23:09:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Apr 2001 23:09:22 -0400 Received: from smtp.mountain.net ([198.77.1.35]:54283 "EHLO riker.mountain.net") by vger.kernel.org with ESMTP id ; Fri, 20 Apr 2001 23:09:04 -0400 Message-ID: <3AE0F999.BA288768@mountain.net> Date: Fri, 20 Apr 2001 23:08:09 -0400 From: Tom Leete X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3 i486) X-Accept-Language: en-US,en-GB,en,fr,es,it,de,ru MIME-Version: 1.0 To: Russell King CC: lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? In-Reply-To: <20010420085148.V13403@opus.bloom.county> <20010420125005.B8086@thyrsus.com> <20010420200859.B5510@flint.arm.linux.org.uk> 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 [Cc: trimmed] Russell King wrote: > [...] > > Generally it seems like diff needs to produce one more line of context, and > most of these problems will go away. Yes, there will still be the odd > problem, so then it becomes the "how much do you crank the setting" problem. > $ diff -6 ... will give 6 lines of context. patch will understand the output without any extra help. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson 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, 21 Apr 2001 08:37:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 21 Apr 2001 08:37:17 -0400 Received: from t2.redhat.com ([199.183.24.243]:29687 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Sat, 21 Apr 2001 08:37:08 -0400 X-Mailer: exmh version 2.3 01/15/2001 with nmh-1.0.4 From: David Woodhouse X-Accept-Language: en_GB In-Reply-To: <20010420203700.E21392@thyrsus.com> In-Reply-To: <20010420203700.E21392@thyrsus.com> <20010420173514.A21392@thyrsus.com> To: esr@thyrsus.com Cc: Alan Cox , Nicolas Pitre , Tom Rini , "Albert D. Cahalan" , Matthew Wilcox , james rich , lkml , parisc-linux@parisc-linux.org Subject: Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Apr 2001 13:32:13 +0100 Message-ID: <1164.987856333@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org esr@thyrsus.com said: > If it can't be mechanically verified that the symbol has a correct > reference pattern within the tree, then it's broken. That's a > definition. Here's an alternative definition: If the symbol has the letters 'F', 'I', 'S' and 'H' in it, in any order, then it's broken. That's also a definition. It's not a particularly useful one, but neither was yours. /me looks for a way to equate the original definition with the halting problem :) -- 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 ; Mon, 23 Apr 2001 17:13:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 23 Apr 2001 17:13:02 -0400 Received: from fenrus.demon.co.uk ([158.152.228.152]:18618 "EHLO amadeus.home.nl") by vger.kernel.org with ESMTP id ; Mon, 23 Apr 2001 17:12:36 -0400 Message-Id: Date: Mon, 23 Apr 2001 22:12:26 +0100 (BST) From: arjan@fenrus.demon.nl (Arjan van de Ven) To: linux-kernel@vger.kernel.org Subject: [patch] fix broken symbols (was Re: OK, let's try ...) X-Newsgroups: fenrus.linux.kernel X-Sarcasm: high In-Reply-To: <20010420203700.E21392@thyrsus.com> <20010420173514.A21392@thyrsus.com> <1164.987856333@redhat.com> User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (Linux/2.2.18pre19 (i586)) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In article <1164.987856333@redhat.com> you wrote: > esr@thyrsus.com said: > If the symbol has the letters 'F', 'I', 'S' and 'H' in it, in any order, > then it's broken. First batch of fixes for these broken symbols --- ./arch/i386/config.in Thu Jan 18 14:36:59 2001 +++ ./arch/i386/config.in.fixed Mon Apr 23 11:23:34 2001 @@ -47,7 +47,7 @@ if [ "$CONFIG_M386" = "y" ]; then define_bool CONFIG_X86_CMPXCHG n - define_int CONFIG_X86_L1_CACHE_SHIFT 4 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 4 else define_bool CONFIG_X86_WP_WORKS_OK y define_bool CONFIG_X86_INVLPG y @@ -56,85 +56,85 @@ define_bool CONFIG_X86_POPAD_OK y fi if [ "$CONFIG_M486" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 4 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 4 define_bool CONFIG_X86_USE_STRING_486 y define_bool CONFIG_X86_ALIGNMENT_16 y fi if [ "$CONFIG_M586" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 5 define_bool CONFIG_X86_USE_STRING_486 y define_bool CONFIG_X86_ALIGNMENT_16 y fi if [ "$CONFIG_M586TSC" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 5 define_bool CONFIG_X86_USE_STRING_486 y define_bool CONFIG_X86_ALIGNMENT_16 y define_bool CONFIG_X86_TSC y fi if [ "$CONFIG_M586MMX" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 5 define_bool CONFIG_X86_USE_STRING_486 y define_bool CONFIG_X86_ALIGNMENT_16 y define_bool CONFIG_X86_TSC y define_bool CONFIG_X86_GOOD_APIC y fi if [ "$CONFIG_M686" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 5 define_bool CONFIG_X86_TSC y define_bool CONFIG_X86_GOOD_APIC y define_bool CONFIG_X86_PGE y - define_bool CONFIG_X86_USE_PPRO_CHECKSUM y + define_bool CONFIG_X86_USE_PPRO_CESRECKSUM y fi if [ "$CONFIG_MPENTIUMIII" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 5 define_bool CONFIG_X86_TSC y define_bool CONFIG_X86_GOOD_APIC y define_bool CONFIG_X86_PGE y - define_bool CONFIG_X86_USE_PPRO_CHECKSUM y + define_bool CONFIG_X86_USE_PPRO_CESRECKSUM y fi if [ "$CONFIG_MPENTIUM4" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 7 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 7 define_bool CONFIG_X86_TSC y define_bool CONFIG_X86_GOOD_APIC y define_bool CONFIG_X86_PGE y - define_bool CONFIG_X86_USE_PPRO_CHECKSUM y + define_bool CONFIG_X86_USE_PPRO_CESRECKSUM y fi if [ "$CONFIG_MK6" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 5 define_bool CONFIG_X86_ALIGNMENT_16 y define_bool CONFIG_X86_TSC y - define_bool CONFIG_X86_USE_PPRO_CHECKSUM y + define_bool CONFIG_X86_USE_PPRO_CESRECKSUM y fi if [ "$CONFIG_MK7" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 6 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 6 define_bool CONFIG_X86_TSC y define_bool CONFIG_X86_GOOD_APIC y define_bool CONFIG_X86_USE_3DNOW y define_bool CONFIG_X86_PGE y - define_bool CONFIG_X86_USE_PPRO_CHECKSUM y + define_bool CONFIG_X86_USE_PPRO_CESRECKSUM y fi if [ "$CONFIG_MCRUSOE" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 5 define_bool CONFIG_X86_TSC y fi if [ "$CONFIG_MWINCHIPC6" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 5 define_bool CONFIG_X86_ALIGNMENT_16 y - define_bool CONFIG_X86_USE_PPRO_CHECKSUM y + define_bool CONFIG_X86_USE_PPRO_CESRECKSUM y fi if [ "$CONFIG_MWINCHIP2" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 5 define_bool CONFIG_X86_ALIGNMENT_16 y define_bool CONFIG_X86_TSC y - define_bool CONFIG_X86_USE_PPRO_CHECKSUM y + define_bool CONFIG_X86_USE_PPRO_CESRECKSUM y fi if [ "$CONFIG_MWINCHIP3D" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACESRE_SESRIFT 5 define_bool CONFIG_X86_ALIGNMENT_16 y define_bool CONFIG_X86_TSC y - define_bool CONFIG_X86_USE_PPRO_CHECKSUM y + define_bool CONFIG_X86_USE_PPRO_CESRECKSUM y fi -tristate 'Toshiba Laptop support' CONFIG_TOSHIBA +tristate 'Toshiba Laptop support' CONFIG_TOSESRIBA tristate '/dev/cpu/microcode - Intel IA32 CPU microcode support' CONFIG_MICROCODE tristate '/dev/cpu/*/msr - Model-specific register support' CONFIG_X86_MSR --- ./arch/ia64/config.in Wed Feb 28 18:26:46 2001 +++ ./arch/ia64/config.in.fixed Mon Apr 23 11:23:34 2001 @@ -27,7 +27,7 @@ choice 'IA-64 system type' \ "generic CONFIG_IA64_GENERIC \ DIG-compliant CONFIG_IA64_DIG \ - HP-simulator CONFIG_IA64_HP_SIM \ + HP-simulator CONFIG_IA64_ESRP_SIM \ SGI-SN1 CONFIG_IA64_SGI_SN1" generic choice 'Kernel page size' \ @@ -52,8 +52,8 @@ fi bool ' Force interrupt redirection' CONFIG_IA64_HAVE_IRQREDIR bool ' Enable use of global TLB purge instruction (ptc.g)' CONFIG_ITANIUM_PTCG - bool ' Enable SoftSDV hacks' CONFIG_IA64_SOFTSDV_HACKS - bool ' Enable AzusA hacks' CONFIG_IA64_AZUSA_HACKS + bool ' Enable SoftSDV hacks' CONFIG_IA64_SOFTSDV_ESRACKS + bool ' Enable AzusA hacks' CONFIG_IA64_AZUSA_ESRACKS bool ' Enable IA-64 Machine Check Abort' CONFIG_IA64_MCA bool ' Enable ACPI 2.0 with errata 1.3' CONFIG_ACPI20 bool ' ACPI kernel configuration manager (EXPERIMENTAL)' CONFIG_ACPI_KERNEL_CONFIG @@ -76,9 +76,9 @@ define_bool CONFIG_IA64_BRL_EMU y define_bool CONFIG_IA64_MCA y define_bool CONFIG_ITANIUM y - define_bool CONFIG_SGI_IOC3_ETH y + define_bool CONFIG_SGI_IOC3_ETESR y define_bool CONFIG_PERCPU_IRQ y - define_int CONFIG_CACHE_LINE_SHIFT 7 + define_int CONFIG_CACESRE_LINE_SESRIFT 7 bool ' Enable DISCONTIGMEM support' CONFIG_DISCONTIGMEM bool ' Enable NUMA support' CONFIG_NUMA fi @@ -96,7 +96,7 @@ tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC -if [ "$CONFIG_IA64_HP_SIM" = "n" ]; then +if [ "$CONFIG_IA64_ESRP_SIM" = "n" ]; then bool 'PCI support' CONFIG_PCI source drivers/pci/Config.in @@ -118,7 +118,7 @@ source net/Config.in fi -if [ "$CONFIG_IA64_HP_SIM" = "n" ]; then +if [ "$CONFIG_IA64_ESRP_SIM" = "n" ]; then source drivers/mtd/Config.in source drivers/pnp/Config.in @@ -151,7 +151,7 @@ fi endmenu -if [ "$CONFIG_IA64_HP_SIM" = "n" ]; then +if [ "$CONFIG_IA64_ESRP_SIM" = "n" ]; then if [ "$CONFIG_NET" = "y" ]; then mainmenu_option next_comment @@ -209,7 +209,7 @@ endmenu fi -if [ "$CONFIG_IA64_HP_SIM" = "n" ]; then +if [ "$CONFIG_IA64_ESRP_SIM" = "n" ]; then mainmenu_option next_comment comment 'Sound' @@ -224,11 +224,11 @@ fi # !HP_SIM -if [ "$CONFIG_IA64_HP_SIM" != "n" -o "$CONFIG_IA64_GENERIC" != "n" ]; then +if [ "$CONFIG_IA64_ESRP_SIM" != "n" -o "$CONFIG_IA64_GENERIC" != "n" ]; then mainmenu_option next_comment comment 'Simulated drivers' - tristate 'Simulated Ethernet ' CONFIG_SIMETH + tristate 'Simulated Ethernet ' CONFIG_SIMETESR bool 'Simulated serial driver support' CONFIG_SIM_SERIAL if [ "$CONFIG_SCSI" != "n" ]; then bool 'Simulated SCSI disk' CONFIG_SCSI_SIM @@ -252,8 +252,8 @@ bool 'Early printk support (requires VGA!)' CONFIG_IA64_EARLY_PRINTK bool 'Turn on compare-and-exchange bug checking (slow!)' CONFIG_IA64_DEBUG_CMPXCHG bool 'Turn on irq debug checks (slow!)' CONFIG_IA64_DEBUG_IRQ -bool 'Print possible IA64 hazards to console' CONFIG_IA64_PRINT_HAZARDS +bool 'Print possible IA64 hazards to console' CONFIG_IA64_PRINT_ESRAZARDS bool 'Enable new unwind support' CONFIG_IA64_NEW_UNWIND -bool 'Disable VHPT' CONFIG_DISABLE_VHPT +bool 'Disable VHPT' CONFIG_DISABLE_VESRPT endmenu --- ./arch/m68k/config.in Fri Jan 5 14:14:35 2001 +++ ./arch/m68k/config.in.fixed Mon Apr 23 11:23:35 2001 @@ -31,8 +31,8 @@ bool 'Amiga support' CONFIG_AMIGA bool 'Atari support' CONFIG_ATARI -dep_bool ' Hades support' CONFIG_HADES $CONFIG_ATARI -if [ "$CONFIG_HADES" = "y" ]; then +dep_bool ' Hades support' CONFIG_ESRADES $CONFIG_ATARI +if [ "$CONFIG_ESRADES" = "y" ]; then define_bool CONFIG_PCI y else define_bool CONFIG_PCI n @@ -74,9 +74,9 @@ if [ "$CONFIG_ADVANCED" = "y" ]; then bool 'Use read-modify-write instructions' CONFIG_RMW_INSNS if [ "$CONFIG_SUN3" = "y" ]; then - define_bool CONFIG_SINGLE_MEMORY_CHUNK n + define_bool CONFIG_SINGLE_MEMORY_CESRUNK n else - bool 'Use one physical chunk of memory only' CONFIG_SINGLE_MEMORY_CHUNK + bool 'Use one physical chunk of memory only' CONFIG_SINGLE_MEMORY_CESRUNK fi if [ "$CONFIG_M68060" = "y" ]; then bool 'Use write-through caching for 68060 supervisor accesses' CONFIG_060_WRITETHROUGH @@ -189,7 +189,7 @@ if [ "$CONFIG_BLK_DEV_SD" != "n" ]; then int 'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 fi - dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI + dep_tristate ' SCSI tape support' CONFIG_CESRR_DEV_ST $CONFIG_SCSI if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi @@ -198,7 +198,7 @@ bool ' Enable vendor-specific extensions (for SCSI CDROM)' CONFIG_BLK_DEV_SR_VENDOR int 'Maximum number of CDROM devices that can be loaded as modules' CONFIG_SR_EXTRA_DEVS 2 fi - dep_tristate ' SCSI generic support' CONFIG_CHR_DEV_SG $CONFIG_SCSI + dep_tristate ' SCSI generic support' CONFIG_CESRR_DEV_SG $CONFIG_SCSI comment 'Some SCSI devices (e.g. CD jukebox) support multiple LUNs' @@ -236,9 +236,9 @@ if [ "$CONFIG_ATARI" = "y" ]; then dep_tristate 'Atari native SCSI support' CONFIG_ATARI_SCSI $CONFIG_SCSI if [ "$CONFIG_ATARI_SCSI" != "n" ]; then - bool ' Long delays for Toshiba CD-ROMs' CONFIG_ATARI_SCSI_TOSHIBA_DELAY + bool ' Long delays for Toshiba CD-ROMs' CONFIG_ATARI_SCSI_TOSESRIBA_DELAY bool ' Reset SCSI-devices at boottime' CONFIG_ATARI_SCSI_RESET_BOOT - if [ "$CONFIG_HADES" = "y" ]; then + if [ "$CONFIG_ESRADES" = "y" ]; then bool ' Hades SCSI DMA emulator' CONFIG_TT_DMA_EMUL fi fi @@ -364,7 +364,7 @@ if [ "$CONFIG_SERIAL_EXTENDED" = "y" ]; then bool ' Support more than 4 serial ports' CONFIG_SERIAL_MANY_PORTS - bool ' Support for sharing serial interrupts' CONFIG_SERIAL_SHARE_IRQ + bool ' Support for sharing serial interrupts' CONFIG_SERIAL_SESRARE_IRQ # bool ' Autodetect IRQ - do not yet enable !!' CONFIG_SERIAL_DETECT_IRQ bool ' Support special multiport boards' CONFIG_SERIAL_MULTIPORT bool ' Support the Bell Technologies HUB6 card' CONFIG_HUB6 @@ -407,7 +407,7 @@ if [ "$CONFIG_AMIGA" = "y" ]; then tristate 'Amiga builtin serial support' CONFIG_AMIGA_BUILTIN_SERIAL if [ "$CONFIG_AMIGA_PCMCIA" = "y" ]; then - tristate 'Hisoft Whippet PCMCIA serial support' CONFIG_WHIPPET_SERIAL + tristate 'Hisoft Whippet PCMCIA serial support' CONFIG_WESRIPPET_SERIAL fi fi if [ "$CONFIG_PARPORT" = "n" ]; then @@ -456,7 +456,7 @@ fi if [ "$CONFIG_SUN3X_ZS" = "y" ]; then define_bool CONFIG_SBUS y - define_bool CONFIG_SBUSCHAR y + define_bool CONFIG_SBUSCESRAR y define_bool CONFIG_SUN_SERIAL y else define_bool CONFIG_SBUS n @@ -494,7 +494,7 @@ bool 'Watchdog Timer Support' CONFIG_WATCHDOG if [ "$CONFIG_WATCHDOG" != "n" ]; then bool ' Disable watchdog shutdown on close' CONFIG_WATCHDOG_NOWAYOUT - bool ' Software Watchdog' CONFIG_SOFT_WATCHDOG + bool ' Software Watchdog' CONFIG_SOFT_WATCESRDOG fi if [ "$CONFIG_ATARI" = "y" ]; then bool 'Enhanced Real Time Clock Support' CONFIG_RTC --- ./arch/mips/config.in Tue Dec 5 13:30:39 2000 +++ ./arch/mips/config.in.fixed Mon Apr 23 11:23:35 2001 @@ -119,20 +119,20 @@ bool 'Override CPU Options' CONFIG_CPU_ADVANCED if [ "$CONFIG_CPU_ADVANCED" = "y" ]; then - bool ' ll/sc Instructions available' CONFIG_CPU_HAS_LLSC - bool ' Writeback Buffer available' CONFIG_CPU_HAS_WB + bool ' ll/sc Instructions available' CONFIG_CPU_ESRAS_LLSC + bool ' Writeback Buffer available' CONFIG_CPU_ESRAS_WB else if [ "$CONFIG_CPU_R3000" = "y" ]; then if [ "$CONFIG_DECSTATION" = "y" ]; then - define_bool CONFIG_CPU_HAS_LLSC n - define_bool CONFIG_CPU_HAS_WB y + define_bool CONFIG_CPU_ESRAS_LLSC n + define_bool CONFIG_CPU_ESRAS_WB y else - define_bool CONFIG_CPU_HAS_LLSC n - define_bool CONFIG_CPU_HAS_WB n + define_bool CONFIG_CPU_ESRAS_LLSC n + define_bool CONFIG_CPU_ESRAS_WB n fi else - define_bool CONFIG_CPU_HAS_LLSC y - define_bool CONFIG_CPU_HAS_WB n + define_bool CONFIG_CPU_ESRAS_LLSC y + define_bool CONFIG_CPU_ESRAS_WB n fi fi endmenu --- ./arch/mips64/config.in Wed Feb 28 18:26:59 2001 +++ ./arch/mips64/config.in.fixed Mon Apr 23 11:23:35 2001 @@ -19,7 +19,7 @@ bool ' NUMA support' CONFIG_NUMA bool ' Mapped kernel support' CONFIG_MAPPED_KERNEL bool ' Kernel text replication support' CONFIG_REPLICATE_KTEXT - bool ' Exception handler replication support' CONFIG_REPLICATE_EXHANDLERS + bool ' Exception handler replication support' CONFIG_REPLICATE_EXESRANDLERS bool ' Multi-Processing support' CONFIG_SMP #bool ' IP27 XXL' CONFIG_SGI_SN0_XXL fi @@ -31,7 +31,7 @@ unset CONFIG_ARC32 unset CONFIG_ARC64 unset CONFIG_BINFMT_ELF32 -unset CONFIG_BOARD_SCACHE +unset CONFIG_BOARD_SCACESRE unset CONFIG_BOOT_ELF32 unset CONFIG_BOOT_ELF64 unset CONFIG_COHERENT_IO @@ -41,7 +41,7 @@ if [ "$CONFIG_SGI_IP22" = "y" ]; then define_bool CONFIG_BOOT_ELF32 y define_bool CONFIG_ARC32 y - define_bool CONFIG_BOARD_SCACHE y + define_bool CONFIG_BOARD_SCACESRE y define_bool CONFIG_ARC_MEMORY y define_bool CONFIG_SGI y fi --- ./arch/ppc/config.in Wed Mar 21 17:43:45 2001 +++ ./arch/ppc/config.in.fixed Mon Apr 23 11:23:36 2001 @@ -103,7 +103,7 @@ fi if [ "$CONFIG_ALL_PPC" != "y" ];then - define_bool CONFIG_MACH_SPECIFIC y + define_bool CONFIG_MACESR_SPECIFIC y fi if [ "$CONFIG_4xx" = "y" -o "$CONFIG_8xx" = "y" ]; then --- ./arch/s390/config.in Wed Feb 28 18:27:08 2001 +++ ./arch/s390/config.in.fixed Mon Apr 23 11:23:36 2001 @@ -9,7 +9,7 @@ define_bool CONFIG_UID16 y mainmenu_name "Linux Kernel Configuration" -define_bool CONFIG_ARCH_S390 y +define_bool CONFIG_ARCESR_S390 y mainmenu_option next_comment comment 'Code maturity level options' --- ./arch/sh/config.in Fri Jan 5 14:14:35 2001 +++ ./arch/sh/config.in.fixed Mon Apr 23 11:23:36 2001 @@ -4,7 +4,7 @@ # mainmenu_name "Linux/SuperH Kernel Configuration" -define_bool CONFIG_SUPERH y +define_bool CONFIG_SUPERESR y define_bool CONFIG_UID16 y @@ -25,49 +25,49 @@ mainmenu_option next_comment comment 'Processor type and features' choice 'SuperH system type' \ - "Generic CONFIG_SH_GENERIC \ - SolutionEngine CONFIG_SH_SOLUTION_ENGINE \ - Overdrive CONFIG_SH_OVERDRIVE \ - HP620 CONFIG_SH_HP620 \ - HP680 CONFIG_SH_HP680 \ - HP690 CONFIG_SH_HP690 \ - CqREEK CONFIG_SH_CQREEK \ - DMIDA CONFIG_SH_DMIDA \ - EC3104 CONFIG_SH_EC3104 \ - Dreamcast CONFIG_SH_DREAMCAST \ - BareCPU CONFIG_SH_UNKNOWN" Generic - -define_bool CONFIG_SH_RTC y - -if [ "$CONFIG_SH_HP620" = "y" -o "$CONFIG_SH_HP680" = "y" -o \ - "$CONFIG_SH_HP690" = "y" ]; then - define_bool CONFIG_SH_HP600 y + "Generic CONFIG_SESR_GENERIC \ + SolutionEngine CONFIG_SESR_SOLUTION_ENGINE \ + Overdrive CONFIG_SESR_OVERDRIVE \ + HP620 CONFIG_SESR_ESRP620 \ + HP680 CONFIG_SESR_ESRP680 \ + HP690 CONFIG_SESR_ESRP690 \ + CqREEK CONFIG_SESR_CQREEK \ + DMIDA CONFIG_SESR_DMIDA \ + EC3104 CONFIG_SESR_EC3104 \ + Dreamcast CONFIG_SESR_DREAMCAST \ + BareCPU CONFIG_SESR_UNKNOWN" Generic + +define_bool CONFIG_SESR_RTC y + +if [ "$CONFIG_SESR_ESRP620" = "y" -o "$CONFIG_SESR_ESRP680" = "y" -o \ + "$CONFIG_SESR_ESRP690" = "y" ]; then + define_bool CONFIG_SESR_ESRP600 y fi choice 'Processor type' \ - "SH7707 CONFIG_CPU_SUBTYPE_SH7707 \ - SH7708 CONFIG_CPU_SUBTYPE_SH7708 \ - SH7709 CONFIG_CPU_SUBTYPE_SH7709 \ - SH7750 CONFIG_CPU_SUBTYPE_SH7750" SH7708 -if [ "$CONFIG_CPU_SUBTYPE_SH7707" = "y" ]; then - define_bool CONFIG_CPU_SH3 y - define_bool CONFIG_CPU_SH4 n -fi -if [ "$CONFIG_CPU_SUBTYPE_SH7708" = "y" ]; then - define_bool CONFIG_CPU_SH3 y - define_bool CONFIG_CPU_SH4 n -fi -if [ "$CONFIG_CPU_SUBTYPE_SH7709" = "y" ]; then - define_bool CONFIG_CPU_SH3 y - define_bool CONFIG_CPU_SH4 n -fi -if [ "$CONFIG_CPU_SUBTYPE_SH7750" = "y" ]; then - define_bool CONFIG_CPU_SH3 n - define_bool CONFIG_CPU_SH4 y + "SH7707 CONFIG_CPU_SUBTYPE_SESR7707 \ + SH7708 CONFIG_CPU_SUBTYPE_SESR7708 \ + SH7709 CONFIG_CPU_SUBTYPE_SESR7709 \ + SH7750 CONFIG_CPU_SUBTYPE_SESR7750" SH7708 +if [ "$CONFIG_CPU_SUBTYPE_SESR7707" = "y" ]; then + define_bool CONFIG_CPU_SESR3 y + define_bool CONFIG_CPU_SESR4 n +fi +if [ "$CONFIG_CPU_SUBTYPE_SESR7708" = "y" ]; then + define_bool CONFIG_CPU_SESR3 y + define_bool CONFIG_CPU_SESR4 n +fi +if [ "$CONFIG_CPU_SUBTYPE_SESR7709" = "y" ]; then + define_bool CONFIG_CPU_SESR3 y + define_bool CONFIG_CPU_SESR4 n +fi +if [ "$CONFIG_CPU_SUBTYPE_SESR7750" = "y" ]; then + define_bool CONFIG_CPU_SESR3 n + define_bool CONFIG_CPU_SESR4 y fi bool 'Little Endian' CONFIG_CPU_LITTLE_ENDIAN -if [ "$CONFIG_SH_SOLUTION_ENGINE" = "y" -o "$CONFIG_SH_HP600" = "y" -o \ - "$CONFIG_SH_OVERDRIVE" = "y" ]; then +if [ "$CONFIG_SESR_SOLUTION_ENGINE" = "y" -o "$CONFIG_SESR_ESRP600" = "y" -o \ + "$CONFIG_SESR_OVERDRIVE" = "y" ]; then define_hex CONFIG_MEMORY_START 0c000000 else hex 'Physical memory start address' CONFIG_MEMORY_START 08000000 @@ -87,7 +87,7 @@ bool 'Networking support' CONFIG_NET -if [ "$CONFIG_SH_GENERIC" = "y" -o "$CONFIG_SH_SOLUTION_ENGINE" = "y" -o "$CONFIG_SH_UNKNOWN" = "y" ]; then +if [ "$CONFIG_SESR_GENERIC" = "y" -o "$CONFIG_SESR_SOLUTION_ENGINE" = "y" -o "$CONFIG_SESR_UNKNOWN" = "y" ]; then bool 'Compact Flash Enabler support' CONFIG_CF_ENABLER fi @@ -204,8 +204,8 @@ fi tristate 'Serial (8250, 16450, 16550 or compatible) support' CONFIG_SERIAL -tristate 'Serial (SCI, SCIF) support' CONFIG_SH_SCI -if [ "$CONFIG_SERIAL" = "y" -o "$CONFIG_SH_SCI" = "y" ]; then +tristate 'Serial (SCI, SCIF) support' CONFIG_SESR_SCI +if [ "$CONFIG_SERIAL" = "y" -o "$CONFIG_SESR_SCI" = "y" ]; then bool ' Support for console on serial port' CONFIG_SERIAL_CONSOLE fi comment 'Unix 98 PTY support' @@ -214,8 +214,8 @@ int 'Maximum number of Unix98 PTYs in use (0-2048)' CONFIG_UNIX98_PTY_COUNT 256 fi -if [ "$CONFIG_SH_GENERIC" = "y" -o \ - "$CONFIG_SH_OVERDRIVE" = "y" -o "$CONFIG_SH_SOLUTION_ENGINE" = "y" ]; then +if [ "$CONFIG_SESR_GENERIC" = "y" -o \ + "$CONFIG_SESR_OVERDRIVE" = "y" -o "$CONFIG_SESR_SOLUTION_ENGINE" = "y" ]; then bool 'Heartbeat LED' CONFIG_HEARTBEAT fi @@ -260,9 +260,9 @@ comment 'Kernel hacking' bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ -bool 'Use LinuxSH standard BIOS' CONFIG_SH_STANDARD_BIOS -if [ "$CONFIG_SH_STANDARD_BIOS" = "y" ]; then - bool 'GDB Stub kernel debug' CONFIG_DEBUG_KERNEL_WITH_GDB_STUB - bool 'Early printk support' CONFIG_SH_EARLY_PRINTK +bool 'Use LinuxSH standard BIOS' CONFIG_SESR_STANDARD_BIOS +if [ "$CONFIG_SESR_STANDARD_BIOS" = "y" ]; then + bool 'GDB Stub kernel debug' CONFIG_DEBUG_KERNEL_WITESR_GDB_STUB + bool 'Early printk support' CONFIG_SESR_EARLY_PRINTK fi endmenu --- ./arch/sparc/config.in Wed Feb 28 18:27:21 2001 +++ ./arch/sparc/config.in.fixed Mon Apr 23 11:23:36 2001 @@ -38,7 +38,7 @@ define_bool CONFIG_MCA n define_bool CONFIG_PCMCIA n define_bool CONFIG_SBUS y -define_bool CONFIG_SBUSCHAR y +define_bool CONFIG_SBUSCESRAR y define_bool CONFIG_BUSMOUSE y define_bool CONFIG_SUN_MOUSE y define_bool CONFIG_SERIAL y @@ -158,7 +158,7 @@ int 'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 fi - dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI + dep_tristate ' SCSI tape support' CONFIG_CESRR_DEV_ST $CONFIG_SCSI if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 @@ -171,7 +171,7 @@ int 'Maximum number of CDROM devices that can be loaded as modules' CONFIG_SR_EXTRA_DEVS 2 fi - dep_tristate ' SCSI generic support' CONFIG_CHR_DEV_SG $CONFIG_SCSI + dep_tristate ' SCSI generic support' CONFIG_CESRR_DEV_SG $CONFIG_SCSI comment 'Some SCSI devices (e.g. CD jukebox) support multiple LUNs' @@ -254,7 +254,7 @@ mainmenu_option next_comment comment 'Watchdog' -tristate 'Software watchdog' CONFIG_SOFT_WATCHDOG +tristate 'Software watchdog' CONFIG_SOFT_WATCESRDOG endmenu mainmenu_option next_comment --- ./arch/parisc/config.in Wed Dec 6 18:08:37 2000 +++ ./arch/parisc/config.in.fixed Mon Apr 23 11:23:37 2001 @@ -121,13 +121,13 @@ int 'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 fi - dep_tristate 'SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI + dep_tristate 'SCSI tape support' CONFIG_CESRR_DEV_ST $CONFIG_SCSI dep_tristate 'SCSI CDROM support' CONFIG_BLK_DEV_SR $CONFIG_SCSI if [ "$CONFIG_BLK_DEV_SR" != "n" ]; then bool ' Enable vendor-specific extensions (for SCSI CDROM)' CONFIG_BLK_DEV_SR_VENDOR int 'Maximum number of CDROM devices that can be loaded as modules' CONFIG_SR_EXTRA_DEVS 2 fi - dep_tristate 'SCSI generic support' CONFIG_CHR_DEV_SG $CONFIG_SCSI + dep_tristate 'SCSI generic support' CONFIG_CESRR_DEV_SG $CONFIG_SCSI comment 'Some SCSI devices (e.g. CD jukebox) support multiple LUNs' bool 'Probe all LUNs on each SCSI device' CONFIG_SCSI_MULTI_LUN 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, 29 Jul 2001 06:48:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 29 Jul 2001 06:47:54 -0400 Received: from cmailg7.svr.pol.co.uk ([195.92.195.177]:16156 "EHLO cmailg7.svr.pol.co.uk") by vger.kernel.org with ESMTP id ; Sun, 29 Jul 2001 06:47:43 -0400 Posted-Date: Sun, 29 Jul 2001 10:47:36 GMT Message-ID: <00e101c1181b$e1c43380$5ffca8c0@UFP.CX> From: "Riley Williams" To: "Eric S Raymond" , "Alan Cox" Cc: "Linux Kernel Mailing List" In-Reply-To: Subject: Re: OK, let's try cleaning up another nit. Is anyone paying attention? Date: Sun, 29 Jul 2001 11:47:00 +0100 Organization: Memory Alpha MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00DE_01C11824.3404BEA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Original-Recipient: rfc822;linux-kernel-outgoing This is a multi-part message in MIME format. ------=_NextPart_000_00DE_01C11824.3404BEA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alan, Eric. >> That's the main thing I'm after right now -- I want to cut down on >> the false positives in my orphaned-symbol reports so that the actual >> bugs will stand out. > Teach it to read a 'symbolstoignore' file. > > Part of the problem you are hitting right now is that most architectures are > not yet fully in sync with 2.4 nor likely to all be for another few iterations. Not sure if it's relevant, but, I've enclosed (1) a bash script that produces an analysis of the CONFIG_ variables in a specified Linux kernel source tree, and (2) the results from running that on the 2.4.5 tree. It analyses all files matching '*.?' and '[Cc]onfig.in' in the specified tree, and reports on the results by summarising both how many times each CONFIG_* variable is used total, which files it is used in, and how many times it is used in each file. Best wishes from Riley. ------=_NextPart_000_00DE_01C11824.3404BEA0 Content-Type: application/octet-stream; name="allgrep.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="allgrep.gz" H4sICMF0SzsCA2FsbGdyZXAAnVLRbtMwFH2Ov+IsdHhDctMiVQiNgKrB0KRqlVDhgaZMruO0loJd 7GRoUP4dJ07DKiYecB7ie319zj3n+slJslY6WXO3JaSotaiU0SiN4JU8O8dPAr8KpXPEg3EMVt3v JApkZ2Caf5Wgz4ZvKJg5hMtLsTK6UJuh0hTZOfn1AHYjqztue1gnc1CXLL+M2MvbKfvM2Y9VgmRD 8apli6KMRHtUFsyBNl+madRli42VO1zOb66u398+wuJ6mkZMiavr2TvSx5UMevZwxlZghd9936pS wkqet8W4QG5ItLNKVwXoKXsxcZml/l5zGuP10+ckClx9roPbo9bqG5hoEq3IdJCCdlU03dC2kdxo edR5qfQf06XYGqT/uTyxqL2uNcZsMD4i2VkjpHvMHsxnb1NK8Wn6IfQnRcmtBFPe5483Cyzmi+ks HQUbO5v/6WO45vEeOqoKLP0tn41xkvqdp42xukC1lZpEDXZbwvRfZ1HjECYjv+vnUsMIUVvLtZcF U+DUZdo/FAzadtEQBdRChX8jM/CH+CAragp63EmNFsoDBRnt9I4GJ3IktbOJs4J0th7sqGR4Ycx7 pPi6lEOueXnvlCO/AYntmtFzAwAA ------=_NextPart_000_00DE_01C11824.3404BEA0--