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, 5 May 2001 19:27:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 5 May 2001 19:27:12 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:22023 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Sat, 5 May 2001 19:26:59 -0400 Date: Sat, 5 May 2001 19:27:31 -0400 From: "Eric S. Raymond" To: CML2 , kbuild-devel@lists.sourceforge.net Subject: CML2 design philosophy heads-up Message-ID: <20010505192731.A2374@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , CML2 , kbuild-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 I've said before on these lists that one of the purposes of CML2's single-apex tree design is to move the configuration dialog away from low-level platform- specific questions towards higher-level questions about policy or intentions. Or to put another way: away from hardware, towards capabilities. As a concrete example, the CML2 rulesfile master for the m68k port tree now has a section that looks like this: # These were separate questions in CML1. They enable on-board peripheral # controllers in single-board computers. derive MVME147_NET from MVME147 & NET_ETHERNET derive MVME147_SCC from MVME147 & SERIAL derive MVME147_SCSI from MVME147 & SCSI derive MVME16x_NET from MVME16x & NET_ETHERNET derive MVME16x_SCC from MVME16x & SERIAL derive MVME16x_SCSI from MVME16x & SCSI derive BVME6000_NET from BVME6000 & NET_ETHERNET derive BVME6000_SCC from BVME6000 & SERIAL derive BVME6000_SCSI from BVME6000 & SCSI # These were separate questions in CML1 derive MAC_SCC from MAC & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI If it isn't obvious, the intent is that if you specify (say) both MVME147 (a machine type) and SERIAL (a capability) you automatically get the specific driver support under MVME147_SCC. This is different from the CML1 approach, which generally involved explicitly specifying each driver with mutual dependencies described (if at all) in Configure.help. I've created a number of derivations of this kind recently. I'm not going out of my way to do this, but what I am trying to do is reduce the number of symbols undocumented in Configure.help to zero (I've got it down to 243 from 547 when I started). When I can eliminate the need for a configuration question and associated help by writing this kind of formula, I'm doing so. This note is a heads-up. If others with a stake in the configuration system (port managers, etc.) have objections to moving further in this direction, I need to hear about it, and about what you think we should be doing instead. -- 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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 6 May 2001 08:55:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 6 May 2001 08:55:11 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:31749 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Sun, 6 May 2001 08:55:07 -0400 Subject: Re: CML2 design philosophy heads-up To: esr@thyrsus.com Date: Sun, 6 May 2001 13:58:49 +0100 (BST) Cc: linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> from "Eric S. Raymond" at May 05, 2001 07:27:31 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 > # These were separate questions in CML1 > derive MAC_SCC from MAC & SERIAL > derive MAC_SCSI from MAC & SCSI > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI Not all Mac's use the SCC if they have serial Not all Mac's use the same SCSI controller Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 7 May 2001 14:03:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 7 May 2001 14:03:17 -0400 Received: from cpe-24-221-152-185.az.sprintbbd.net ([24.221.152.185]:9220 "EHLO Opus.bloom.county") by vger.kernel.org with ESMTP id ; Mon, 7 May 2001 14:03:08 -0400 Date: Mon, 7 May 2001 10:59:50 -0700 From: Tom Rini To: Alan Cox Cc: esr@thyrsus.com, CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010507105950.A771@opus.bloom.county> In-Reply-To: <20010505192731.A2374@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Sun, May 06, 2001 at 01:58:49PM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 06, 2001 at 01:58:49PM +0100, Alan Cox wrote: > > # These were separate questions in CML1 > > derive MAC_SCC from MAC & SERIAL > > derive MAC_SCSI from MAC & SCSI > > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI > > Not all Mac's use the SCC if they have serial > Not all Mac's use the same SCSI controller Yes, but in this case 'MAC' means m68k mac, which this _might_ be valid, but I never did get Linux up and running on the m68ks I had.. But Alan's point is a good one. There are _lots_ of cases you can't get away with things like this, unless you get very fine grained. In fact, it would be much eaiser to do this seperately from the kernel. Ie another, possibly/probably _not_ inkernel config tool which asks what machine you have, picks lots of sane defaults and setups a kernel config for you. This is _sort of_ what PPC does right now with the large number of 'default configs' (arch/ppc/configs). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 7 May 2001 21:31:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 7 May 2001 21:31:48 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:34827 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Mon, 7 May 2001 21:31:38 -0400 Date: Mon, 7 May 2001 21:31:40 -0400 From: "Eric S. Raymond" To: Tom Rini Cc: Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010507213140.I16535@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Tom Rini , Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010507105950.A771@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010507105950.A771@opus.bloom.county>; from trini@kernel.crashing.org on Mon, May 07, 2001 at 10:59:50AM -0700 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Tom Rini : > On Sun, May 06, 2001 at 01:58:49PM +0100, Alan Cox wrote: > > > # These were separate questions in CML1 > > > derive MAC_SCC from MAC & SERIAL > > > derive MAC_SCSI from MAC & SCSI > > > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI > > > > Not all Mac's use the SCC if they have serial > > Not all Mac's use the same SCSI controller > > Yes, but in this case 'MAC' means m68k mac, which this _might_ be valid, but > I never did get Linux up and running on the m68ks I had.. Exactly. In fact we can be more specific -- the "Macintoshes" in question are the old-fashioned NuBus-based 68k toaster boxes, not the more recent designs with a PCI bus. Relevant stuff in the Configure.help implies that MAC_SCC and MAC_SCSI enable support for the on-board hardware built into those puppies. > But Alan's point is a good one. There are _lots_ of cases you can't get away > with things like this, unless you get very fine grained. In fact, it would > be much eaiser to do this seperately from the kernel. Ie another, > possibly/probably _not_ inkernel config tool which asks what machine you > have, picks lots of sane defaults and setups a kernel config for you. This > is _sort of_ what PPC does right now with the large number of 'default > configs' (arch/ppc/configs). You're really talking about a different issue here, autoconfiguration rather than static dependencies. Giacomo Catenazzi is working on that. -- Eric S. Raymond Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, "Abbey's Road", 1979 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 7 May 2001 21:47:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 7 May 2001 21:47:00 -0400 Received: from cpe-24-221-152-185.az.sprintbbd.net ([24.221.152.185]:58896 "EHLO Opus.bloom.county") by vger.kernel.org with ESMTP id ; Mon, 7 May 2001 21:46:51 -0400 Date: Mon, 7 May 2001 18:43:15 -0700 From: Tom Rini To: "Eric S. Raymond" , Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010507184315.A2378@opus.bloom.county> In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010507105950.A771@opus.bloom.county> <20010507213140.I16535@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010507213140.I16535@thyrsus.com>; from esr@thyrsus.com on Mon, May 07, 2001 at 09:31:40PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 07, 2001 at 09:31:40PM -0400, Eric S. Raymond wrote: > Tom Rini : [snip] > Exactly. In fact we can be more specific -- the "Macintoshes" in > question are the old-fashioned NuBus-based 68k toaster boxes, not the > more recent designs with a PCI bus. Relevant stuff in the > Configure.help implies that MAC_SCC and MAC_SCSI enable support for > the on-board hardware built into those puppies. > > > But Alan's point is a good one. There are _lots_ of cases you can't get away > > with things like this, unless you get very fine grained. In fact, it would > > be much eaiser to do this seperately from the kernel. Ie another, > > possibly/probably _not_ inkernel config tool which asks what machine you > > have, picks lots of sane defaults and setups a kernel config for you. This > > is _sort of_ what PPC does right now with the large number of 'default > > configs' (arch/ppc/configs). > > You're really talking about a different issue here, autoconfiguration > rather than static dependencies. Giacomo Catenazzi is working on that. Only sort-of. There are some cases where you can get away with that. Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, always (right?) On other arches (someone brought this up before) it could be PC, it could be something else. My point is there are only some cases where you can get away with asking for serial and knowing the driver. I've given this some thought before, and at least on PPC, you can at best segment off some drivers as depending on family X, but family X doesn't mean you have part Y. The other thing to keep in mind is I'm sure there's lots of unintentionally correct bits. In short, please be very careful when you change a symbol from a question to a derive. You're bound to piss off someone :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 7 May 2001 21:56:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 7 May 2001 21:56:10 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:50443 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Mon, 7 May 2001 21:56:05 -0400 Date: Mon, 7 May 2001 21:56:18 -0400 From: "Eric S. Raymond" To: Tom Rini Cc: Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010507215618.B21552@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Tom Rini , Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010507105950.A771@opus.bloom.county> <20010507213140.I16535@thyrsus.com> <20010507184315.A2378@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010507184315.A2378@opus.bloom.county>; from trini@kernel.crashing.org on Mon, May 07, 2001 at 06:43:15PM -0700 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Tom Rini : > Only sort-of. There are some cases where you can get away with that. > Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, > always (right?) Yes. So the right answer there isn't to use a derivation but to say: require X86 and PARPORT implies PARPORT_PC unless X86==n suppress PARPORT_PC which forces PARPORT_PC==y and makes the question invisible on X86 machines, but leaves the question visible on all others. -- Eric S. Raymond The real point of audits is to instill fear, not to extract revenue; the IRS aims at winning through intimidation and (thereby) getting maximum voluntary compliance -- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 8 May 2001 03:00:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 8 May 2001 03:00:14 -0400 Received: from smtp1.cern.ch ([137.138.128.38]:53006 "EHLO smtp1.cern.ch") by vger.kernel.org with ESMTP id ; Tue, 8 May 2001 03:00:04 -0400 Date: Tue, 8 May 2001 08:59:41 +0200 From: Jamie Lokier To: "Eric S. Raymond" , Tom Rini , Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010508085941.B17720@pcep-jamie.cern.ch> In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010507105950.A771@opus.bloom.county> <20010507213140.I16535@thyrsus.com> <20010507184315.A2378@opus.bloom.county> <20010507215618.B21552@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: <20010507215618.B21552@thyrsus.com>; from esr@thyrsus.com on Mon, May 07, 2001 at 09:56:18PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Eric S. Raymond wrote: > Tom Rini : > > Only sort-of. There are some cases where you can get away with that. > > Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, > > always (right?) > > Yes. So the right answer there isn't to use a derivation but to say: > > require X86 and PARPORT implies PARPORT_PC > unless X86==n suppress PARPORT_PC > > which forces PARPORT_PC==y and makes the question invisible on X86 machines, > but leaves the question visible on all others. Which is unfortunately wrong if you want the parport subsystem on x86 but won't be using the parport_pc driver with it. I.e. you'll be using some other driver which isn't part of the kernel tree. Perhaps a modified version of parport_pc, perhaps something else. The default should be PARPORT_PC==y, but it's actually valid for some applications to _require_ PARPORT_PC==n or PARPORT_PC==m. -- Jamie From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 8 May 2001 02:58:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 8 May 2001 02:58:11 -0400 Received: from khan.acc.umu.se ([130.239.18.139]:58869 "EHLO khan.acc.umu.se") by vger.kernel.org with ESMTP id ; Tue, 8 May 2001 02:58:02 -0400 Date: Tue, 8 May 2001 08:57:40 +0200 From: David Weinehall To: "Eric S. Raymond" , Tom Rini , Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010508085739.A17485@khan.acc.umu.se> In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010507105950.A771@opus.bloom.county> <20010507213140.I16535@thyrsus.com> <20010507184315.A2378@opus.bloom.county> <20010507215618.B21552@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20010507215618.B21552@thyrsus.com>; from esr@thyrsus.com on Mon, May 07, 2001 at 09:56:18PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 07, 2001 at 09:56:18PM -0400, Eric S. Raymond wrote: > Tom Rini : > > Only sort-of. There are some cases where you can get away with > > that. Probably. eg If you ask for PARPORT, on x86 that means yes > > to PARPORT_PC, always (right?) > > Yes. So the right answer there isn't to use a derivation but to say: > > require X86 and PARPORT implies PARPORT_PC > unless X86==n suppress PARPORT_PC > > which forces PARPORT_PC==y and makes the question invisible on X86 > machines, but leaves the question visible on all others. Yes, but there are quite a lot of people who don't want parport/serial/whatever compiled into their kernels at all, eventhough they have an x86. Think low-memory systems or similar. /David _ _ // David Weinehall /> Northern lights wander \\ // Project MCA Linux hacker // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 8 May 2001 03:00:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 8 May 2001 03:00:34 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:50956 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Tue, 8 May 2001 03:00:29 -0400 Date: Tue, 8 May 2001 03:00:35 -0400 From: "Eric S. Raymond" To: David Weinehall Cc: Tom Rini , Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010508030035.A15697@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , David Weinehall , Tom Rini , Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010507105950.A771@opus.bloom.county> <20010507213140.I16535@thyrsus.com> <20010507184315.A2378@opus.bloom.county> <20010507215618.B21552@thyrsus.com> <20010508085739.A17485@khan.acc.umu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010508085739.A17485@khan.acc.umu.se>; from tao@acc.umu.se on Tue, May 08, 2001 at 08:57:40AM +0200 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 David Weinehall : > > require X86 and PARPORT implies PARPORT_PC > > unless X86==n suppress PARPORT_PC > > > > which forces PARPORT_PC==y and makes the question invisible on X86 > > machines, but leaves the question visible on all others. > > Yes, but there are quite a lot of people who don't want > parport/serial/whatever compiled into their kernels at all, > eventhough they have an x86. Think low-memory systems or similar. That's OK. Neither of these constraints says PARPORT must be compiled in. Look at the conditionals carefully. -- Eric S. Raymond "...The Bill of Rights is a literal and absolute document. The First Amendment doesn't say you have a right to speak out unless the government has a 'compelling interest' in censoring the Internet. The Second Amendment doesn't say you have the right to keep and bear arms until some madman plants a bomb. The Fourth Amendment doesn't say you have the right to be secure from search and seizure unless some FBI agent thinks you fit the profile of a terrorist. The government has no right to interfere with any of these freedoms under any circumstances." -- Harry Browne, 1996 USA presidential candidate, Libertarian Party From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 8 May 2001 03:16:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 8 May 2001 03:16:07 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:52748 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Tue, 8 May 2001 03:16:03 -0400 Date: Tue, 8 May 2001 03:15:11 -0400 From: "Eric S. Raymond" To: Jamie Lokier Cc: Tom Rini , Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010508031511.A15782@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Jamie Lokier , Tom Rini , Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010507105950.A771@opus.bloom.county> <20010507213140.I16535@thyrsus.com> <20010507184315.A2378@opus.bloom.county> <20010507215618.B21552@thyrsus.com> <20010508085941.B17720@pcep-jamie.cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010508085941.B17720@pcep-jamie.cern.ch>; from lk@tantalophile.demon.co.uk on Tue, May 08, 2001 at 08:59:41AM +0200 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 Jamie Lokier : > Which is unfortunately wrong if you want the parport subsystem on x86 > but won't be using the parport_pc driver with it. I.e. you'll be using > some other driver which isn't part of the kernel tree. Perhaps a > modified version of parport_pc, perhaps something else. If you're integrating drivers that aren't in the kernel tree, you can and should patch the CML2 rulebase to compensate. So your patch for the modified driver should comment out the PARPORT_PC==PARPORT requirement. Problem solved. More generally, arguments of the form "Non-mainline custom hack X could invalidate constraint Y, therefore we can't have Y in the rulebase" are dangerous -- I suspect you could reduce your set of constraints to nil very quickly that way, and thus badly screw over the 99% of people who just want to build a more or less stock kernel. -- Eric S. Raymond The abortion rights and gun control debates are twin aspects of a deeper question --- does an individual ever have the right to make decisions that are literally life-or-death? And if not the individual, who does? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 8 May 2001 05:38:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 8 May 2001 05:38:11 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:34827 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Tue, 8 May 2001 05:37:56 -0400 Subject: Re: CML2 design philosophy heads-up To: trini@kernel.crashing.org (Tom Rini) Date: Mon, 7 May 2001 22:57:23 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), esr@thyrsus.com, linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <20010507105950.A771@opus.bloom.county> from "Tom Rini" at May 07, 2001 10:59:50 AM 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 > > Not all Mac's use the same SCSI controller > > Yes, but in this case 'MAC' means m68k mac, which this _might_ be valid, but > I never did get Linux up and running on the m68ks I had.. 68K macs use the 53C80 and 53C9x controllers > But Alan's point is a good one. There are _lots_ of cases you can't get away > with things like this, unless you get very fine grained. In fact, it would > be much eaiser to do this seperately from the kernel. Ie another, There are also a lot of config options that are implied by your setup in an embedded enviromment but which you dont actually want because you didnt wire them Second guessing is not ideal. As a 'make the default config nice' trick - great From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 8 May 2001 05:44:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 8 May 2001 05:44:42 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:63500 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Tue, 8 May 2001 05:44:30 -0400 Date: Tue, 8 May 2001 05:44:32 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: Tom Rini , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010508054432.A16487@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , Tom Rini , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010507105950.A771@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Mon, May 07, 2001 at 10:57:23PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > There are also a lot of config options that are implied by your setup in > an embedded enviromment but which you dont actually want because you didnt > wire them Well, then, you don't specify the guard capability! If your MV147 isn't wired for serial, then leave SERIAL off. The point of the derivation is exactly to let you do that. -- 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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 8 May 2001 08:45:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 8 May 2001 08:44:42 -0400 Received: from hermine.idb.hist.no ([158.38.50.15]:18950 "HELO hermine.idb.hist.no") by vger.kernel.org with SMTP id ; Tue, 8 May 2001 08:43:22 -0400 Message-ID: <3AF7E9D0.E3097FA1@idb.hist.no> Date: Tue, 08 May 2001 14:42:56 +0200 From: Helge Hafting X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4-pre7 i686) X-Accept-Language: no, en MIME-Version: 1.0 To: Alan Cox , linux-kernel@vger.kernel.org, esr@thyrsus.com Subject: Re: CML2 design philosophy heads-up In-Reply-To: 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 Alan Cox wrote: > > But Alan's point is a good one. There are _lots_ of cases you can't get away > > with things like this, unless you get very fine grained. In fact, it would > > be much eaiser to do this seperately from the kernel. Ie another, > > There are also a lot of config options that are implied by your setup in > an embedded enviromment but which you dont actually want because you didnt > wire them > > Second guessing is not ideal. As a 'make the default config nice' trick - great This is easy without changing CML2. Make another config option for auto-enabling hardware you "probably have" Rules of the form "X86 and PARPORT implies PARPORT_PC" can then be transformed to "X86 and PARPORT and PROBABLE_HARDWARE implies PARPORT_PC" Those who want a nice & easy config may then turn PROBABLE_HARDWARE on. Those who want tricks like using only nonstandard (hi-performance?) serial ports on their pc and save memory on skipping drivers for the built-in stuff can do so by turning the probable setting off. Helge Hafting From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 8 May 2001 10:15:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 8 May 2001 10:15:35 -0400 Received: from 13dyn127.delft.casema.net ([212.64.76.127]:40976 "EHLO abraracourcix.bitwizard.nl") by vger.kernel.org with ESMTP id ; Tue, 8 May 2001 10:15:23 -0400 Message-Id: <200105081415.QAA00401@cave.bitwizard.nl> Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010508031511.A15782@thyrsus.com> from "Eric S. Raymond" at "May 8, 2001 03:15:11 am" To: "Eric S. Raymond" Date: Tue, 8 May 2001 16:15:08 +0200 (MEST) CC: Jamie Lokier , Tom Rini , Alan Cox , CML2 , kbuild-devel@lists.sourceforge.net From: R.E.Wolff@BitWizard.nl (Rogier Wolff) X-Mailer: ELM [version 2.4ME+ PL60 (25)] 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 Eric S. Raymond wrote: > More generally, arguments of the form "Non-mainline custom hack X > could invalidate constraint Y, therefore we can't have Y in the > rulebase" are dangerous -- I suspect you could reduce your set of > constraints to nil very quickly that way, and thus badly screw over > the 99% of people who just want to build a more or less stock kernel. Eric, Still being able to use the "tool" is useful! So I want a "don't mess with me" mode where I'd get more control than 99% of the lusers.... Roger. -- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. 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, 13 May 2001 10:23:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 13 May 2001 10:23:12 -0400 Received: from smtp1.cern.ch ([137.138.128.38]:51211 "EHLO smtp1.cern.ch") by vger.kernel.org with ESMTP id ; Sun, 13 May 2001 10:23:07 -0400 To: esr@thyrsus.com Cc: CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010505192731.A2374@thyrsus.com> From: Jes Sorensen Date: 13 May 2001 16:22:59 +0200 In-Reply-To: "Eric S. Raymond"'s message of "Sat, 5 May 2001 19:27:31 -0400" Message-ID: User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 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 >>>>> "Eric" == Eric S Raymond writes: Eric> I've said before on these lists that one of the purposes of Eric> CML2's single-apex tree design is to move the configuration Eric> dialog away from low-level platform- specific questions towards Eric> higher-level questions about policy or intentions. Eric> Or to put another way: away from hardware, towards capabilities. Eric> As a concrete example, the CML2 rulesfile master for the m68k Eric> port tree now has a section that looks like this: Eric> # These were separate questions in CML1. They enable on-board Eric> peripheral # controllers in single-board computers. derive Eric> MVME147_NET from MVME147 & NET_ETHERNET derive MVME147_SCC from Eric> MVME147 & SERIAL derive MVME147_SCSI from MVME147 & SCSI derive Eric> MVME16x_NET from MVME16x & NET_ETHERNET derive MVME16x_SCC from Eric> MVME16x & SERIAL derive MVME16x_SCSI from MVME16x & SCSI derive Eric> BVME6000_NET from BVME6000 & NET_ETHERNET derive BVME6000_SCC Eric> from BVME6000 & SERIAL derive BVME6000_SCSI from BVME6000 & SCSI Not all cards have all features, not all users wants to enable all features. Eric> # These were separate questions in CML1 derive MAC_SCC from MAC Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from Eric> (SUN3 | SUN3X) & SCSI As Alan already pointed out thats assumption is invalid. Eric> This is different from the CML1 approach, which generally Eric> involved explicitly specifying each driver with mutual Eric> dependencies described (if at all) in Configure.help. Yes and it should stay like that. If Richard had wanted all those features enabled per default when an MVME setting was selected, he would have done it in the config.in file, which is perfectly valid to do so today. Eric> This note is a heads-up. If others with a stake in the Eric> configuration system (port managers, etc.) have objections to Eric> moving further in this direction, I need to hear about it, and Eric> about what you think we should be doing instead. -- href="http://www.tuxedo.org/~esr/">Eric S. Raymond Yes I have objections. I thought I had made this clear a long time ago: Go play with another port and leave the m68k port alone. Thank you 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 ; Sun, 13 May 2001 11:26:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 13 May 2001 11:26:32 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:27654 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Sun, 13 May 2001 11:26:16 -0400 Date: Sun, 13 May 2001 11:25:44 -0400 From: "Eric S. Raymond" To: Jes Sorensen Cc: CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010513112543.A16121@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Jes Sorensen , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jes@sunsite.dk on Sun, May 13, 2001 at 04:22:59PM +0200 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 Jes Sorensen : > Not all cards have all features, not all users wants to enable all > features. Yes, I understand that. You're not reading the derivations correctly. Let's take an example: derive MVME147_SCSI from MVME147 & SCSI This doesn't turn on MVME147_SCSI on every MVME147 board. It turns on MVME147_SCSI when both MVME147 *and SCCI* are on. So to suppress MVME147_SCSI, one just leaves SCCI off. All these derived symbols will still be controllable. The difference is that instead of being controlled by a low-level hardware-oriented question they're controlled by a capability or subsystem symbol like SCSI, NET_ETHERNET, or SERIAL. > Eric> # These were separate questions in CML1 derive MAC_SCC from MAC > Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from > Eric> (SUN3 | SUN3X) & SCSI > > As Alan already pointed out thats assumption is invalid. I'm in touch with Ray Knight directly and will fix this as he requests. > Yes I have objections. I thought I had made this clear a long time > ago: Go play with another port and leave the m68k port alone. Does this mean you'll take over maintaining the CML2 rules files for the m68k port, so I don't have to? That would be wonderful. Reasoned objections can change my behavior. Grunting territorial challenges at me will not. You have two options: (1) persuade Linus that the whole CML2 thing is a bad idea and should be dropped, or (2) work with me to correct any errors I have made and improve the system. Growling at me and hoping I go away won't work, not when I've invested a year's effort in this project. -- Eric S. Raymond As with the Christian religion, the worst advertisement for Socialism is its adherents. -- George Orwell From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 May 2001 16:32:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 May 2001 16:32:29 -0400 Received: from smtp1.cern.ch ([137.138.128.38]:29700 "EHLO smtp1.cern.ch") by vger.kernel.org with ESMTP id ; Tue, 15 May 2001 16:32:11 -0400 To: esr@thyrsus.com Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> From: Jes Sorensen Date: 15 May 2001 22:32:00 +0200 In-Reply-To: "Eric S. Raymond"'s message of "Sun, 13 May 2001 11:25:44 -0400" Message-ID: User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 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 >>>>> "Eric" == Eric S Raymond writes: Eric> Jes Sorensen : Eric> # These were separate questions in CML1 derive MAC_SCC from MAC Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from Eric> (SUN3 | SUN3X) & SCSI >> As Alan already pointed out thats assumption is invalid. Eric> I'm in touch with Ray Knight directly and will fix this as he Eric> requests. If Ray wants to fix things, it's just fine with me. >> Yes I have objections. I thought I had made this clear a long time >> ago: Go play with another port and leave the m68k port alone. Eric> Does this mean you'll take over maintaining the CML2 rules files Eric> for the m68k port, so I don't have to? That would be wonderful. For a start, so far there has been no reason whatsoever to change the format of definitions. Eric> Reasoned objections can change my behavior. Grunting Eric> territorial challenges at me will not. You have two options: Eric> (1) persuade Linus that the whole CML2 thing is a bad idea and Eric> should be dropped, or (2) work with me to correct any errors I Eric> have made and improve the system. Growling at me and hoping I Eric> go away won't work, not when I've invested a year's effort in Eric> this project. So far you have only been irritating developers for no reason. What I asked you to do is to NOT change whatever config options developers developers felt were necessary to introduce. If you want to change the format of the config.in files go ahead. Messing around with the config options themselves is *not* for you to do, nor are you to impose a more restrictive space for people to work in. 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 ; Tue, 15 May 2001 17:34:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 May 2001 17:34:19 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:39174 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Tue, 15 May 2001 17:34:06 -0400 Date: Tue, 15 May 2001 17:33:16 -0400 From: "Eric S. Raymond" To: Jes Sorensen Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010515173316.A8308@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Jes Sorensen , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jes@sunsite.dk on Tue, May 15, 2001 at 10:32:00PM +0200 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 Jes Sorensen : > If Ray wants to fix things, it's just fine with me. I have corrected the Mac dependencies as Ray directed. > Eric> Does this mean you'll take over maintaining the CML2 rules files > Eric> for the m68k port, so I don't have to? That would be wonderful. > > For a start, so far there has been no reason whatsoever to change the > format of definitions. The judgment of the kbuild team is unanimous that you are mistaken on this. That's the five people (excluding me) who wrote and maintained the CML1 code. *They* said that code had to go, Linus has concurred with their judgment, and the argument is over. > So far you have only been irritating developers for no reason. What I > asked you to do is to NOT change whatever config options developers > developers felt were necessary to introduce. If you want to change the > format of the config.in files go ahead. Messing around with the config > options themselves is *not* for you to do, nor are you to impose a > more restrictive space for people to work in. If you persist in misunderstanding what I am doing, you are neither going to be able to influence my behavior nor to persuade other people that it is wrong. Listen carefully, please: 1. The CML2 system neither changes the CONFIG_ symbol namespace nor assumes any changes in it. (Earlier versions did, but Greg Banks showed me how to avoid needing to.) 2. The ruleset changes I have made simplify the configuration process, but they do *not* in any way restrict the space of configurations that are possible. By design, every valid (consistent) configuration in CML1 can be generated in CML2. I treat departures from that rule as rulesfile bugs and fix them (as I just did at Ray Knight's instruction). 3. I do not have (nor do I seek) the power to "impose" anything on anyone. You really ought to give CML2 a technical evaluation yourself before you flame me again. Much of what you seem to think you know is not true. -- Eric S. Raymond According to the National Crime Survey administered by the Bureau of the Census and the National Institute of Justice, it was found that only 12 percent of those who use a gun to resist assault are injured, as are 17 percent of those who use a gun to resist robbery. These percentages are 27 and 25 percent, respectively, if they passively comply with the felon's demands. Three times as many were injured if they used other means of resistance. -- G. Kleck, "Policy Lessons from Recent Gun Control Research," 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, 17 May 2001 03:24:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 17 May 2001 03:24:31 -0400 Received: from zeus.kernel.org ([209.10.41.242]:63403 "EHLO zeus.kernel.org") by vger.kernel.org with ESMTP id ; Thu, 17 May 2001 03:24:17 -0400 Date: Tue, 15 May 2001 14:43:27 +0000 From: Pavel Machek To: "Eric S. Raymond" , Jes Sorensen , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010515144325.A38@toy.ucw.cz> In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010513112543.A16121@thyrsus.com>; from esr@thyrsus.com on Sun, May 13, 2001 at 11:25:44AM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi! > > Not all cards have all features, not all users wants to enable all > > features. > > Yes, I understand that. You're not reading the derivations correctly. > Let's take an example: > > derive MVME147_SCSI from MVME147 & SCSI > > This doesn't turn on MVME147_SCSI on every MVME147 board. It turns > on MVME147_SCSI when both MVME147 *and SCCI* are on. So to suppress > MVME147_SCSI, one just leaves SCCI off. And If I want scsi-on-atapi emulation but not vme147_scsi? You are right that your solution is right most of the time, but there always will be nasty corner cases like that. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 17 May 2001 03:28:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 17 May 2001 03:28:05 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:27663 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Thu, 17 May 2001 03:27:45 -0400 Date: Thu, 17 May 2001 03:26:36 -0400 From: "Eric S. Raymond" To: Pavel Machek Cc: Jes Sorensen , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010517032636.A1109@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Pavel Machek , Jes Sorensen , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515144325.A38@toy.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515144325.A38@toy.ucw.cz>; from pavel@suse.cz on Tue, May 15, 2001 at 02:43:27PM +0000 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Pavel Machek : > And If I want scsi-on-atapi emulation but not vme147_scsi? Help me understand this case, please. What is scsi-on-atapi? Is SCSI on when you enable it? And is it a realistic case for an SBC? The CML2 constraint language is very flexible. I can make it do the right thing, if I know what the right thing is. -- 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 ; Thu, 17 May 2001 03:48:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 17 May 2001 03:48:18 -0400 Received: from deliverator.sgi.com ([204.94.214.10]:42602 "EHLO deliverator.sgi.com") by vger.kernel.org with ESMTP id ; Thu, 17 May 2001 03:48:14 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: esr@thyrsus.com cc: Pavel Machek , Jes Sorensen , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up In-Reply-To: Your message of "Thu, 17 May 2001 03:26:36 -0400." <20010517032636.A1109@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 May 2001 17:47:41 +1000 Message-ID: <28870.990085661@kao2.melbourne.sgi.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 17 May 2001 03:26:36 -0400, "Eric S. Raymond" wrote: >Pavel Machek : >> And If I want scsi-on-atapi emulation but not vme147_scsi? > >Help me understand this case, please. What is scsi-on-atapi? >Is SCSI on when you enable it? And is it a realistic case for an SBC? SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid layer code but no SCSI hardware drivers. It is a realistic case for an embedded CD-RW appliance. BTW, there is a bug in the current setting of CONFIG_BLK_DEV_IDESCSI. Starting with CONFIG_SCSI unset, you can set BLK_DEV_IDESCSI to y and later set SCSI to n and get a mess, even with make oldconfig. I am discussing the fix with Andre Hendrick, expect BLK_DEV_IDESCSI to move to the SCSI menu. 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, 17 May 2001 05:55:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 17 May 2001 05:55:17 -0400 Received: from munchkin.spectacle-pond.org ([209.192.197.45]:58375 "EHLO munchkin.spectacle-pond.org") by vger.kernel.org with ESMTP id ; Thu, 17 May 2001 05:54:57 -0400 Date: Thu, 17 May 2001 05:35:49 -0400 From: Michael Meissner To: Keith Owens Cc: esr@thyrsus.com, Pavel Machek , Jes Sorensen , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010517053549.A17562@munchkin.spectacle-pond.org> In-Reply-To: <20010517032636.A1109@thyrsus.com> <28870.990085661@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <28870.990085661@kao2.melbourne.sgi.com>; from kaos@ocs.com.au on Thu, May 17, 2001 at 05:47:41PM +1000 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote: > On Thu, 17 May 2001 03:26:36 -0400, > "Eric S. Raymond" wrote: > >Pavel Machek : > >> And If I want scsi-on-atapi emulation but not vme147_scsi? > > > >Help me understand this case, please. What is scsi-on-atapi? > >Is SCSI on when you enable it? And is it a realistic case for an SBC? > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid > layer code but no SCSI hardware drivers. It is a realistic case for an > embedded CD-RW appliance. Or alternatively, you want to enable SCSI code, with no hardware driver, because you are going to build pcmcia, which builds the scsi drivers only if CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or 1480 scsi card into your pcmcia slot. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: meissner@redhat.com phone: +1 978-486-9304 Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482 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, 17 May 2001 12:36:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 17 May 2001 12:36:33 -0400 Received: from cpe-24-221-152-185.az.sprintbbd.net ([24.221.152.185]:33807 "EHLO Opus.bloom.county") by vger.kernel.org with ESMTP id ; Thu, 17 May 2001 12:36:20 -0400 Date: Thu, 17 May 2001 09:34:11 -0700 From: Tom Rini To: Michael Meissner Cc: Keith Owens , esr@thyrsus.com, CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010517093411.A12740@opus.bloom.county> In-Reply-To: <20010517032636.A1109@thyrsus.com> <28870.990085661@kao2.melbourne.sgi.com> <20010517053549.A17562@munchkin.spectacle-pond.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010517053549.A17562@munchkin.spectacle-pond.org>; from meissner@spectacle-pond.org on Thu, May 17, 2001 at 05:35:49AM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 17, 2001 at 05:35:49AM -0400, Michael Meissner wrote: > On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote: > > On Thu, 17 May 2001 03:26:36 -0400, > > "Eric S. Raymond" wrote: > > >Pavel Machek : > > >> And If I want scsi-on-atapi emulation but not vme147_scsi? > > > > > >Help me understand this case, please. What is scsi-on-atapi? > > >Is SCSI on when you enable it? And is it a realistic case for an SBC? > > > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid > > layer code but no SCSI hardware drivers. It is a realistic case for an > > embedded CD-RW appliance. > > Or alternatively, you want to enable SCSI code, with no hardware driver, > because you are going to build pcmcia, which builds the scsi drivers only if > CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or 1480 scsi > card into your pcmcia slot. Both of these 'problems' assume that you can have IDE or PCMCIA on these particular boxes. Does anyone know if that's actually true? What eric is trying to do, can work, if done very carefully, and in very limited cases as well. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 03:45:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 03:45:06 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:4615 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 03:44:46 -0400 Date: Fri, 18 May 2001 03:43:07 -0400 From: "Eric S. Raymond" To: Tom Rini Cc: Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518034307.A10784@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010517032636.A1109@thyrsus.com> <28870.990085661@kao2.melbourne.sgi.com> <20010517053549.A17562@munchkin.spectacle-pond.org> <20010517093411.A12740@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010517093411.A12740@opus.bloom.county>; from trini@kernel.crashing.org on Thu, May 17, 2001 at 09:34:11AM -0700 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Tom Rini : > > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid > > > layer code but no SCSI hardware drivers. It is a realistic case for an > > > embedded CD-RW appliance. > > > > Or alternatively, you want to enable SCSI code, with no hardware driver, > > because you are going to build pcmcia, which builds the scsi drivers only > > if CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or > > 1480 scsi card into your pcmcia slot. > > Both of these 'problems' assume that you can have IDE or PCMCIA on these > particular boxes. Does anyone know if that's actually true? The answer is: no, you can't. I found a feature list for the MVME147 on the web at . It confirmed what thought I remembered from the Motorola site; no PCMCIA, no IDE/ATAPI. As a matter of fact neither of these technologies existed yet when the board was being designed in the mid-1980s. (The article I found is kind of interesting. It's a dissection of the MVME147's design and history...narrated in first person.) In any case, if this *had* been a problem, the right fix IMO would have been to split the SCSI symbol into SCSI and SCSI_DRIVERS and have constraints that would make SCSI and the presence of any SCSI card imply SCSI_DRIVERS. -- Eric S. Raymond The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, "My First Impression of the U.S.A.", 1921 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, 18 May 2001 04:25:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 04:25:44 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:63242 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 04:25:34 -0400 Subject: Re: CML2 design philosophy heads-up To: esr@thyrsus.com Date: Fri, 18 May 2001 09:20:47 +0100 (BST) Cc: trini@kernel.crashing.org (Tom Rini), meissner@spectacle-pond.org (Michael Meissner), kaos@ocs.com.au (Keith Owens), linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518034307.A10784@thyrsus.com> from "Eric S. Raymond" at May 18, 2001 03:43:07 AM X-Mailer: ELM [version 2.5 PL3] 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 > > Both of these 'problems' assume that you can have IDE or PCMCIA on these > > particular boxes. Does anyone know if that's actually true? > > The answer is: no, you can't. > > I found a feature list for the MVME147 on the web at > . It > confirmed what thought I remembered from the Motorola site; no PCMCIA, > no IDE/ATAPI. As a matter of fact neither of these technologies > existed yet when the board was being designed in the mid-1980s. I was under the impression the MVME had VME bus. So you can hang IDE off it and other gunge. Its also a reference design so you may find MVME147 like boards.. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 10:55:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 10:55:30 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:45576 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 10:55:24 -0400 Date: Fri, 18 May 2001 10:53:53 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518105353.A13684@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518034307.A10784@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, May 18, 2001 at 09:20:47AM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > I was under the impression the MVME had VME bus. So you can hang IDE off it > and other gunge. Its also a reference design so you may find MVME147 like > boards.. Urk. Alan is right, I misinterpreted the original question. There is no on-board support for IDE or PCMCIA, but you could plug in an IDE daughterboard with an IDE drive or a PCMCIA slot. This would be a pretty damn perverse thing to do, however -- there are newer, less expensive, faster, and generally better SBCs that have IDE/ATAPI and PCMCIA built in. On top of that, VMEbus SBCs aren't normally used for consumer devices -- their market is basically industrial-control applications with a side of scientific instrumentation. That being the case, we do face a question of design philosophy, expressed as a policy question about how to design rulesets. Actually two questions: 1. When we have a platform symbol for a reference design like MVME147, do we stick to its spec sheet or consider it representative of all derivatives (which may have other facilities)? I know my answer to this one, which I will implement unless there's strong consensus otherwise. I go for explicitness. If we're going to support MVME147 derivatives and variants in the ruleset, they get their own platform symbols. 2. How much extra tsuris should we accept in order to handle perverse edge cases like this one? There are three ways we can cope: (a) Back off the capability approach. That is, accept that people doing configuration are going to explicitly and exhaustively specify low-level hardware. (b) Add complexity to the ruleset. Split SCSI into SCSI_MIDLEVEL and SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied whenever a SCSI card is configured, etc. (c) Decide not to support this case and document the fact in the rulesfile. If you're going put gunge on the VME bus that replaces the SBC's on-board facilities, you can hand-hack your own configs. I don't want to do (a); it conflicts with my design objective of simplifying configuration enough that Aunt Tillie can do it. I won't do that unless I see a strong consensus that it's the only Right Thing. The larger question in choosing between (b) and (c) is one of the usual ones in programming -- that is, generality vs. maintainability. Is it ever acceptable for the configuration system to deliberately punt an edge case like this one in order to keep from having a combinatorial-complexity explosion in the ruleset? I know what my sense of taste and proportion says. But I'm not going to impose my vision on everybody. If you have an opinion, I'd like to hear it. -- Eric S. Raymond Whether the authorities be invaders or merely local tyrants, the effect of such [gun control] laws is to place the individual at the mercy of the state, unable to resist. -- Robert Anson Heinlein, 1949 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, 18 May 2001 11:11:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:11:43 -0400 Received: from t2.redhat.com ([199.183.24.243]:47867 "HELO executor.cambridge.redhat.com") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 11:11:30 -0400 Message-ID: <3B053B9B.23286E6C@redhat.com> Date: Fri, 18 May 2001 16:11:23 +0100 From: Arjan van de Ven Reply-To: arjanv@redhat.com Organization: Red Hat, Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Eric S. Raymond" , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > (a) Back off the capability approach. That is, accept that > people doing configuration are going to explicitly and > exhaustively specify low-level hardware. > I don't want to do (a); it conflicts with my design objective of > simplifying configuration enough that Aunt Tillie can do it. I won't > do that unless I see a strong consensus that it's the only Right Thing. Aunt Tillie doesn't even know what a kernel is, nor does she want to. I think it's fair to assume that people who configure and compile their own kernel (as opposed to using the distribution supplied ones) know what they are doing. Or at least make something like a "Expert level" question as first question, so that people who DO know what they are doing can select the options they want. Going from "make config" (which has a scary interface for novice users, agreed) to "vi" is NOT progress. Greetings, Arjan van de Ven 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, 18 May 2001 11:10:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:10:03 -0400 Received: from ppp0.ocs.com.au ([203.34.97.3]:13072 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 11:09:47 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: CML2 cc: kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up In-Reply-To: Your message of "Fri, 18 May 2001 10:53:53 -0400." <20010518105353.A13684@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 May 2001 01:09:41 +1000 Message-ID: <1694.990198581@ocs3.ocs-net> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org cc trimmed back to mailing lists only. On Fri, 18 May 2001 10:53:53 -0400, "Eric S. Raymond" wrote: > (a) Back off the capability approach. That is, accept that > people doing configuration are going to explicitly and > exhaustively specify low-level hardware. No, you loose one of the nicer features of CML2. > (b) Add complexity to the ruleset. Split SCSI into SCSI_MIDLEVEL and > SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied > whenever a SCSI card is configured, etc. As a specific case this needs doing anyway, to handle SCSI emulation over IDE, irrespective of the board type. It needs mid layer but no SCSI driver and can be done on a PC right now. As a general question, I prefer selecting machine type foo to mean just that, you get the devices supported by foo. > (c) Decide not to support this case and document the fact in the > rulesfile. If you're going put gunge on the VME bus that replaces > the SBC's on-board facilities, you can hand-hack your own configs. In general this is the best option, if you create a non-standard configuration for machine foo then it is your problem, not everybody else's. 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, 18 May 2001 11:17:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:17:13 -0400 Received: from warden.digitalinsight.com ([208.29.163.2]:46759 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 11:17:02 -0400 From: David Lang To: "Eric S. Raymond" Cc: Alan Cox , Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Date: Fri, 18 May 2001 07:06:11 -0700 (PDT) Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010518105353.A13684@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org if you punt in case C you should then have a mode where all dependancies are ignored and all options are presented to the person ding the config. This is FAR better then forcing them to hand-hack the config file. possibly split the rules file into two parts. part 1. absolute requirements (i.e. if you select a SCSI controller you MUST select SCSI) part 2. simplifications (i.e. if x86 and printer then x86_printer) tehn have a mode where the part 2 rules are not evaluated to handle the corner cases. David Lang On Fri, 18 May 2001, Eric S. Raymond wrote: > Date: Fri, 18 May 2001 10:53:53 -0400 > From: Eric S. Raymond > To: Alan Cox > Cc: Tom Rini , > Michael Meissner , > Keith Owens , CML2 , > kbuild-devel@lists.sourceforge.net > Subject: Re: CML2 design philosophy heads-up > > Alan Cox : > > I was under the impression the MVME had VME bus. So you can hang IDE off it > > and other gunge. Its also a reference design so you may find MVME147 like > > boards.. > > Urk. Alan is right, I misinterpreted the original question. There is > no on-board support for IDE or PCMCIA, but you could plug in an IDE > daughterboard with an IDE drive or a PCMCIA slot. This would be a > pretty damn perverse thing to do, however -- there are newer, less > expensive, faster, and generally better SBCs that have IDE/ATAPI and > PCMCIA built in. On top of that, VMEbus SBCs aren't normally used for > consumer devices -- their market is basically industrial-control > applications with a side of scientific instrumentation. > > That being the case, we do face a question of design > philosophy, expressed as a policy question about how to design > rulesets. Actually two questions: > > 1. When we have a platform symbol for a reference design like MVME147, do > we stick to its spec sheet or consider it representative of all derivatives > (which may have other facilities)? > > I know my answer to this one, which I will implement unless there's > strong consensus otherwise. I go for explicitness. If we're going to > support MVME147 derivatives and variants in the ruleset, they get > their own platform symbols. > > 2. How much extra tsuris should we accept in order to handle > perverse edge cases like this one? There are three ways we > can cope: > > (a) Back off the capability approach. That is, accept that > people doing configuration are going to explicitly and > exhaustively specify low-level hardware. > > (b) Add complexity to the ruleset. Split SCSI into SCSI_MIDLEVEL and > SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied > whenever a SCSI card is configured, etc. > > (c) Decide not to support this case and document the fact in the > rulesfile. If you're going put gunge on the VME bus that replaces > the SBC's on-board facilities, you can hand-hack your own configs. > > I don't want to do (a); it conflicts with my design objective of > simplifying configuration enough that Aunt Tillie can do it. I won't > do that unless I see a strong consensus that it's the only Right Thing. > > The larger question in choosing between (b) and (c) is one of the usual ones > in programming -- that is, generality vs. maintainability. Is it ever > acceptable for the configuration system to deliberately punt an edge case > like this one in order to keep from having a combinatorial-complexity > explosion in the ruleset? > > I know what my sense of taste and proportion says. But I'm not going > to impose my vision on everybody. If you have an opinion, I'd like > to hear it. > -- > Eric S. Raymond > > Whether the authorities be invaders or merely local tyrants, the > effect of such [gun control] laws is to place the individual at the > mercy of the state, unable to resist. > -- Robert Anson Heinlein, 1949 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > 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, 18 May 2001 11:20:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:19:53 -0400 Received: from t2.redhat.com ([199.183.24.243]:48891 "HELO executor.cambridge.redhat.com") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 11:19:44 -0400 Message-ID: <3B053D8A.FF16ECEC@redhat.com> Date: Fri, 18 May 2001 16:19:38 +0100 From: Arjan van de Ven Reply-To: arjanv@redhat.com Organization: Red Hat, Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010518105353.A13684@thyrsus.com> <1694.990198581@ocs3.ocs-net> 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 Keith Owens wrote: > > (c) Decide not to support this case and document the fact in the > > rulesfile. If you're going put gunge on the VME bus that replaces > > the SBC's on-board facilities, you can hand-hack your own configs. > > In general this is the best option, if you create a non-standard > configuration for machine foo then it is your problem, not everybody > else's. If you use a standard configuration, you can use a precompiled kernel as well. Sorry I don't buy this. The point of the kernel configuration is to also allow non-standard configurations. Think about it: the standard pc (PC99 or whatever it is called this year) doesn't have a PS/2 port, only USB. So we can remove even the question from the config system, no? Greetings, Arjan van de Ven 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, 18 May 2001 11:20:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:20:03 -0400 Received: from smtp1.cern.ch ([137.138.128.38]:5126 "EHLO smtp1.cern.ch") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:19:56 -0400 To: esr@thyrsus.com Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> From: Jes Sorensen Date: 18 May 2001 17:19:48 +0200 In-Reply-To: "Eric S. Raymond"'s message of "Tue, 15 May 2001 17:33:16 -0400" Message-ID: User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 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 >>>>> "Eric" == Eric S Raymond writes: Eric> Jes Sorensen : >> For a start, so far there has been no reason whatsoever to change >> the format of definitions. Eric> The judgment of the kbuild team is unanimous that you are Eric> mistaken on this. That's the five people (excluding me) who Eric> wrote and maintained the CML1 code. *They* said that code had Eric> to go, Linus has concurred with their judgment, and the argument Eric> is over. Replacing the code does not require changing the style of the config files. Thats a major problem with CML2, you introduce a new 'let me do everything for you' tool that relies on a programming language that is not being shipped by any major vendor nor does it look like they are planning to do it anytime soon. And even if they start doing so, this is a totally unreasonable requirement, you *must* to make it possible to compile kernels on older distributions without requiring people to update half of their system. On some architectures, the majority of the users are still on glibc 2.0 and other old versions of tools. Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. Nobody disagrees that the Makefiles needs a redesign, however that doesn't mean everything else has to be redisigned in a totally incompatible manner. Eric> If you persist in misunderstanding what I am doing, you are Eric> neither going to be able to influence my behavior nor to Eric> persuade other people that it is wrong. Listen carefully, Eric> please: Oh I don't, on the other hand I see you consistently ignoring the needs and requirements of the users. So far I haven't heard a single developer say something positive about CML2, the most positive I have heard so far has been "whatever", "it's his choice", "I don't care", "I want to hack". The majority are of the "NO!" and "you got to be kiddin'". Eric> 1. The CML2 system neither changes the CONFIG_ symbol namespace Eric> nor assumes any changes in it. (Earlier versions did, but Greg Eric> Banks showed me how to avoid needing to.) Let's just say you didn't exactly give peoiple a good impression with the trolling around on how everybody had to change their option names and how important it was for the world. Eric> 2. The ruleset changes I have made simplify the configuration Eric> process, but they do *not* in any way restrict the space of Eric> configurations that are possible. By design, every valid Eric> (consistent) configuration in CML1 can be generated in CML2. I Eric> treat departures from that rule as rulesfile bugs and fix them Eric> (as I just did at Ray Knight's instruction). What spawned this recent discussion was you wanting to remove config options and automatically enable things instead of giving the users the explicit choice to do so. Now you are trying to tell me that you are not changing things? Eric> 3. I do not have (nor do I seek) the power to "impose" anything Eric> on anyone. We'll let that one stand on display for a few minutes. Eric> You really ought to give CML2 a technical evaluation yourself Eric> before you flame me again. Much of what you seem to think you Eric> know is not true. So far I have had to deal with a number of requests from you trying to impose unreasonable changes on developers. Thats more than plenty for me. I do not have Python2 installed and I do not plan to, if you change CML2 to use a reasonable programming language I might give it a try. Jes PS: And if you could start making your .signature rfc1855 compliant it was be pleasant for all readers of this mailing list. 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, 18 May 2001 11:27:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:27:33 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:53768 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:27:28 -0400 Date: Fri, 18 May 2001 11:26:25 -0400 From: "Eric S. Raymond" To: Arjan van de Ven Cc: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518112625.A14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B053B9B.23286E6C@redhat.com>; from arjanv@redhat.com on Fri, May 18, 2001 at 04:11:23PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Arjan van de Ven : > Aunt Tillie doesn't even know what a kernel is, nor does she want > to. I think it's fair to assume that people who configure and > compile their own kernel (as opposed to using the distribution > supplied ones) know what they are doing. I'd like to break these assumptions. Or at the very least see how far they can be bent. I know this sounds crazy to a lot of hackers, but I think there's a certain amount of unhelpful elitism and self-puffery in the "kernels are hard to configure and they *should* be hard to configure* attitude. Let's give Aunt Tillie a chance to surprise us. > Or at least make something like a "Expert level" question as first > question, so that people who DO know what they are doing can select > the options they want. Already in the plan -- in fact the EXPERT symbol exists in CML2 now. -- Eric S. Raymond It is proper to take alarm at the first experiment on our liberties. We hold this prudent jealousy to be the first duty of citizens and one of the noblest characteristics of the late Revolution. The freemen of America did not wait till usurped power had strengthened itself by exercise and entangled the question in precedents. They saw all the consequences in the principle, and they avoided the consequences by denying the principle. We revere this lesson too much ... to forget it -- James Madison. 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, 18 May 2001 11:37:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:37:43 -0400 Received: from nat-pool-meridian.redhat.com ([199.183.24.200]:46842 "EHLO devserv.devel.redhat.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:37:28 -0400 Date: Fri, 18 May 2001 11:37:26 -0400 From: Arjan van de Ven To: "Eric S. Raymond" Cc: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518113726.A29617@devserv.devel.redhat.com> In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@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: <20010518112625.A14309@thyrsus.com>; from esr@thyrsus.com on Fri, May 18, 2001 at 11:26:25AM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2001 at 11:26:25AM -0400, Eric S. Raymond wrote: > I'd like to break these assumptions. Or at the very least see how far > they can be bent. I know this sounds crazy to a lot of hackers, but > I think there's a certain amount of unhelpful elitism and self-puffery > in the "kernels are hard to configure and they *should* be hard to > configure* attitude. Let's give Aunt Tillie a chance to surprise us. Don't get me wrong. I'm NOT opposed to having a config tool everyone and their aunt can use. I'm opposed to that tool taking away the options expert users have to do what they know is right for them. Thankfully, decent tools for novice users already exists, in the KDE project for example. And if the tool is missing a few things, please improve it instead of forking a new tool with the same goal. Greetings, Arjan van de Ven 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, 18 May 2001 11:34:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:34:23 -0400 Received: from sal.qcc.sk.ca ([198.169.27.3]:271 "HELO sal.qcc.sk.ca") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 11:34:16 -0400 Date: Fri, 18 May 2001 09:34:14 -0600 From: Charles Cazabon To: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518093414.A21164@qcc.sk.ca> In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010518112625.A14309@thyrsus.com>; from esr@thyrsus.com on Fri, May 18, 2001 at 11:26:25AM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Eric S. Raymond wrote: > Arjan van de Ven : > > Aunt Tillie doesn't even know what a kernel is, nor does she want > > to. I think it's fair to assume that people who configure and > > compile their own kernel (as opposed to using the distribution > > supplied ones) know what they are doing. > > I'd like to break these assumptions. Or at the very least see how far > they can be bent. I know this sounds crazy to a lot of hackers, but > I think there's a certain amount of unhelpful elitism and self-puffery > in the "kernels are hard to configure and they *should* be hard to > configure* attitude. Let's give Aunt Tillie a chance to surprise us. Whether this is desirable or not is debatable. The big question is: why on earth would Aunt Tillie _want_ to compile a kernel at all, let alone re-configure one? If she's using Linux, she's installing her distribution's pre-compiled kernel, and has no need for anything else. Simplifying the configuration interface so that "anyone" can use it seems like a waste of effort. If there's an interested novice out there who wants to learn how to configure a kernel, they'll be sufficiently interested to invest an hour or two in learning how the whole process works. Make it as simple as it needs to be, and no simpler. Charles -- ----------------------------------------------------------------------- Charles Cazabon GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ----------------------------------------------------------------------- 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, 18 May 2001 11:41:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:41:03 -0400 Received: from warden.digitalinsight.com ([208.29.163.2]:49108 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 11:40:44 -0400 From: David Lang To: Charles Cazabon Cc: linux-kernel@vger.kernel.org Date: Fri, 18 May 2001 07:30:07 -0700 (PDT) Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010518093414.A21164@qcc.sk.ca> 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 why is it that so many people seem to think that it's a good thing to only use precompiled kernels from the distro? a kernel tuned for a particular machine can boot faster and run faster then a 'stock' kernel. unless you want to replace the kernel compile config options with a similar sized menu to select between precompiled kernels with the correct options (never mind what that will do to the size of the distros to ship so many kernels) David Lang On Fri, 18 May 2001, Charles Cazabon wrote: > Date: Fri, 18 May 2001 09:34:14 -0600 > From: Charles Cazabon > To: linux-kernel@vger.kernel.org > Subject: Re: CML2 design philosophy heads-up > > Eric S. Raymond wrote: > > Arjan van de Ven : > > > Aunt Tillie doesn't even know what a kernel is, nor does she want > > > to. I think it's fair to assume that people who configure and > > > compile their own kernel (as opposed to using the distribution > > > supplied ones) know what they are doing. > > > > I'd like to break these assumptions. Or at the very least see how far > > they can be bent. I know this sounds crazy to a lot of hackers, but > > I think there's a certain amount of unhelpful elitism and self-puffery > > in the "kernels are hard to configure and they *should* be hard to > > configure* attitude. Let's give Aunt Tillie a chance to surprise us. > > Whether this is desirable or not is debatable. The big question is: why on > earth would Aunt Tillie _want_ to compile a kernel at all, let alone > re-configure one? If she's using Linux, she's installing her distribution's > pre-compiled kernel, and has no need for anything else. > > Simplifying the configuration interface so that "anyone" can use it seems like > a waste of effort. If there's an interested novice out there who wants to > learn how to configure a kernel, they'll be sufficiently interested to invest > an hour or two in learning how the whole process works. Make it as simple as > it needs to be, and no simpler. > > Charles > -- > ----------------------------------------------------------------------- > Charles Cazabon > GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ > Any opinions expressed are just that -- my opinions. > ----------------------------------------------------------------------- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > 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, 18 May 2001 11:46:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:46:23 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:24077 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:46:12 -0400 Subject: Re: CML2 design philosophy heads-up To: linux-kernel@discworld.dyndns.org (Charles Cazabon) Date: Fri, 18 May 2001 16:42:47 +0100 (BST) Cc: linux-kernel@vger.kernel.org In-Reply-To: <20010518093414.A21164@qcc.sk.ca> from "Charles Cazabon" at May 18, 2001 09:34:14 AM X-Mailer: ELM [version 2.5 PL3] 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 > Simplifying the configuration interface so that "anyone" can use it seems like > a waste of effort. If there's an interested novice out there who wants to > learn how to configure a kernel, they'll be sufficiently interested to invest > an hour or two in learning how the whole process works. Make it as simple as > it needs to be, and no simpler. Having a simple interface is good. Being guided by probable correct choices helps many people, but it needs to support a simple interface as well as a real one if the two conflict in design goals 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, 18 May 2001 11:43:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:43:03 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:17677 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:42:50 -0400 Subject: Re: CML2 design philosophy heads-up To: esr@thyrsus.com Date: Fri, 18 May 2001 16:38:08 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), trini@kernel.crashing.org (Tom Rini), meissner@spectacle-pond.org (Michael Meissner), kaos@ocs.com.au (Keith Owens), linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518105353.A13684@thyrsus.com> from "Eric S. Raymond" at May 18, 2001 10:53:53 AM X-Mailer: ELM [version 2.5 PL3] 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 > 1. When we have a platform symbol for a reference design like MVME147, do > we stick to its spec sheet or consider it representative of all derivatives > (which may have other facilities)? At most it bounds the busses directly available. I've yet to see VME cardbus adapters but its quite possible. > I don't want to do (a); it conflicts with my design objective of > simplifying configuration enough that Aunt Tillie can do it. I won't > do that unless I see a strong consensus that it's the only Right Thing. Its a good way of getting the defaults right. It may also be an appropriate way of guiding presentation (eg putting the stuff the ruleset says you wont have under a subcategory so you would see CPU type Devices blah blah Other Options IDE disk Cardbus 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, 18 May 2001 11:43:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:43:33 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:19725 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:43:22 -0400 Subject: Re: CML2 design philosophy heads-up To: kaos@ocs.com.au (Keith Owens) Date: Fri, 18 May 2001 16:39:57 +0100 (BST) Cc: linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <1694.990198581@ocs3.ocs-net> from "Keith Owens" at May 19, 2001 01:09:41 AM X-Mailer: ELM [version 2.5 PL3] 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 > > (c) Decide not to support this case and document the fact in the > > rulesfile. If you're going put gunge on the VME bus that replaces > > the SBC's on-board facilities, you can hand-hack your own configs. > > In general this is the best option, if you create a non-standard > configuration for machine foo then it is your problem, not everybody > else's. Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets this whole discussion wouldn't be needed. 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, 18 May 2001 11:45:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:45:03 -0400 Received: from pobox.sibyte.com ([208.12.96.20]:64777 "HELO pobox.sibyte.com") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 11:44:49 -0400 From: Justin Carlson Reply-To: carlson@sibyte.com Organization: Sibyte To: Jes Sorensen Subject: Re: CML2 design philosophy heads-up Date: Fri, 18 May 2001 08:37:30 -0700 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain; charset=US-ASCII Cc: linux-kernel@vger.kernel.org In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010515173316.A8308@thyrsus.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <01051808442800.27946@plugh.sibyte.com> Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 May 2001, Jes Sorensen wrote: > Oh I don't, on the other hand I see you consistently ignoring the > needs and requirements of the users. So far I haven't heard a single > developer say something positive about CML2, the most positive I have > heard so far has been "whatever", "it's his choice", "I don't care", > "I want to hack". The majority are of the "NO!" and "you got to be > kiddin'". Perhaps your hearing has gone more than a bit selective. Please, allow me to be the first to get through: I think CML2 looks very interesting, and while it's not quite primetime yet, it's definitely a movement in the right direction. I'd even go sofar as to say I think CML2 is a GOOD THING. Or perhaps you have a more selective definition of developer? -Justin carlson@sibyte.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 11:47:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:47:15 -0400 Received: from sal.qcc.sk.ca ([198.169.27.3]:1551 "HELO sal.qcc.sk.ca") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 11:47:03 -0400 Date: Fri, 18 May 2001 09:47:02 -0600 From: Charles Cazabon To: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518094702.A21217@qcc.sk.ca> In-Reply-To: <20010518093414.A21164@qcc.sk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from david.lang@digitalinsight.com on Fri, May 18, 2001 at 07:30:07AM -0700 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org David Lang wrote: > > Whether this is desirable or not is debatable. The big question is: why > > on earth would Aunt Tillie _want_ to compile a kernel at all, let alone > > re-configure one? If she's using Linux, she's installing her > > distribution's pre-compiled kernel, and has no need for anything else. > why is it that so many people seem to think that it's a good thing to only > use precompiled kernels from the distro? a kernel tuned for a particular > machine can boot faster and run faster then a 'stock' kernel. I'm not saying it's a good thing. I'm saying that the 5% performance increase that results is not something that the average "I just want to use the system" will even notice, let alone care about. > unless you want to replace the kernel compile config options with a > similar sized menu to select between precompiled kernels with the correct > options (never mind what that will do to the size of the distros to ship > so many kernels) They don't need to ship a mass of kernels. Modern distributions probably don't need to worry about shipping three or four modular kernels. Any user who cares about the minor performance benefits of a custom-configured kernel is going to reconfigure and recompile regardless of how dumbed-down the interface is. Charles -- ----------------------------------------------------------------------- Charles Cazabon GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ----------------------------------------------------------------------- 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, 18 May 2001 11:43:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:43:44 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:56072 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:43:35 -0400 Date: Fri, 18 May 2001 11:42:29 -0400 From: "Eric S. Raymond" To: Jes Sorensen Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518114229.B14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Jes Sorensen , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jes@sunsite.dk on Fri, May 18, 2001 at 05:19:48PM +0200 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 Jes Sorensen : > Oh I don't, on the other hand I see you consistently ignoring the > needs and requirements of the users. Oh, sure. The CML2 NEWS file is ample proof of that. OK, Jes, you've just demonstrated that you're blind to facts and can't be reasoned with. I'll continue listening to everybody else as I've been doing, but I'll specifically ignore *you* until you lose the obstreperous attitude. -- Eric S. Raymond The whole of the Bill [of Rights] is a declaration of the right of the people at large or considered as individuals... It establishes some rights of the individual as unalienable and which consequently, no majority has a right to deprive them of. -- Albert Gallatin, Oct 7 1789 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, 18 May 2001 11:50:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:50:34 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:57352 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:50:25 -0400 Date: Fri, 18 May 2001 11:49:22 -0400 From: "Eric S. Raymond" To: Arjan van de Ven Cc: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518114922.C14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010518113726.A29617@devserv.devel.redhat.com>; from arjanv@redhat.com on Fri, May 18, 2001 at 11:37:26AM -0400 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 Arjan van de Ven : > Don't get me wrong. I'm NOT opposed to having a config tool everyone and > their aunt can use. I'm opposed to that tool taking away the options expert > users have to do what they know is right for them. I'll take that as a vote for (b), to handle even perverse configurations even if it means adding a lot of complexity to the ruleset. -- Eric S. Raymond ...the Federal Judiciary...an irresponsible body, working like gravity by night and by day, gaining a little today and a little tomorrow, and advancing its noiseless step like a thief over the field of jurisdiction until all shall be usurped from the States; and the government of all be consolidated into one. 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, 18 May 2001 11:57:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:57:03 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:34829 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:56:53 -0400 Subject: Re: CML2 design philosophy heads-up To: esr@thyrsus.com Date: Fri, 18 May 2001 16:53:27 +0100 (BST) Cc: jes@sunsite.dk (Jes Sorensen), linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518114229.B14309@thyrsus.com> from "Eric S. Raymond" at May 18, 2001 11:42:29 AM X-Mailer: ELM [version 2.5 PL3] 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 > OK, Jes, you've just demonstrated that you're blind to facts and can't > be reasoned with. I'll continue listening to everybody else as I've > been doing, but I'll specifically ignore *you* until you lose the > obstreperous attitude. >>From here it has me thinking of pots kettles and a rather dark colour... Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 11:54:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 11:54:03 -0400 Received: from mail.reutershealth.com ([204.243.9.36]:12229 "EHLO mail.reutershealth.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:53:51 -0400 Message-ID: <3B054500.2090408@reutershealth.com> Date: Fri, 18 May 2001 11:51:28 -0400 From: John Cowan User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 To: Jes Sorensen CC: esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jes Sorensen wrote: > Telling them to install an updated gcc for kernel compilation > is a necessary evil, which can easily be done without disturbing the > rest of the system. Updating the system's python installation is not a > reasonable request. Au contraire. It is very reasonable to have both python and python2 installed. Having two different gcc versions installed is a big pain in the arse. > So far I haven't heard a single > developer say something positive about CML2, the most positive I have > heard so far has been "whatever", "it's his choice", "I don't care", > "I want to hack". The majority are of the "NO!" and "you got to be > kiddin'". Anonymized hearsay evidence is less than convincing. > Let's just say you didn't exactly give peoiple a good impression with > the trolling around on how everybody had to change their option names > and how important it was for the world. Decidedly bad form to criticize someone for a bug (in this case, a design bug) that's already been fixed. If that behavior starts, who shall escape hanging? > I do not have Python2 installed and I do not plan to, if you > change CML2 to use a reasonable programming language I might give it a > try. Those who don't remember the past are condemned to repeat it. John Cowan, _novus homo_ (Latin for "upstart") -- There is / one art || John Cowan no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein 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, 18 May 2001 12:03:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:03:23 -0400 Received: from mail.reutershealth.com ([204.243.9.36]:19397 "EHLO mail.reutershealth.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 12:03:11 -0400 Message-ID: <3B05473B.70606@reutershealth.com> Date: Fri, 18 May 2001 12:00:59 -0400 From: John Cowan User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: Jes Sorensen , esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> <3B054500.2090408@reutershealth.com> <20010518175843.A9347@caldera.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Christoph Hellwig wrote: > On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote: > >>Jes Sorensen wrote: >> >> >>>Telling them to install an updated gcc for kernel compilation >>>is a necessary evil, which can easily be done without disturbing the >>>rest of the system. Updating the system's python installation is not a >>>reasonable request. >>> >> >>Au contraire. It is very reasonable to have both python and python2 >>installed. Having two different gcc versions installed is a big pain >>in the arse. >> > > Fump. Some distributions do even come with two gcc's out of the box. > With the whole egcs and gcc2.95 (dunno about 3.0) you can even share > the compiler driver if you want. Yes, I should have limited myself to pre-egcs versions. -- There is / one art || John Cowan no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein 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, 18 May 2001 12:01:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:01:36 -0400 Received: from turnover.lancs.ac.uk ([148.88.17.220]:48879 "EHLO helium.chromatix.org.uk") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 12:00:25 -0400 Message-Id: In-Reply-To: <20010518112625.A14309@thyrsus.com> In-Reply-To: <3B053B9B.23286E6C@redhat.com>; from arjanv@redhat.com on Fri, May 18, 2001 at 04:11:23PM +0100 <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 May 2001 16:59:47 +0100 To: esr@thyrsus.com, Arjan van de Ven From: Jonathan Morton Subject: Re: CML2 design philosophy heads-up Cc: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >> Aunt Tillie doesn't even know what a kernel is, nor does she want >> to. I think it's fair to assume that people who configure and >> compile their own kernel (as opposed to using the distribution >> supplied ones) know what they are doing. > >I'd like to break these assumptions. Or at the very least see how far >they can be bent. I know this sounds crazy to a lot of hackers, but >I think there's a certain amount of unhelpful elitism and self-puffery >in the "kernels are hard to configure and they *should* be hard to >configure* attitude. Let's give Aunt Tillie a chance to surprise us. Not everyone falls into the "expert user" and "Aunt Tillie" categories. It's a *very* big grey area. If some semi-computer-literate user (ie. some friends of mine!) wants to upgrade their kernel so they have access to newer hardware (such as a cheap USB webcam), it should be made as simple as possible for them. CML1 doesn't handle that very well, I'd like to see it's replacement do better. So, the first questions should be along the lines of "Do you have (approximately) these kinds of standard configuration?" starting with "x86 PC", "Apple PowerMac" and other sensible defaults - followed by "none of the above". Then later on, things like "Do you have SCSI?" followed by "What type of SCSI card(s)". And under IDE configuration, we have "Do you want IDE-SCSI emulation (useful for CD-writers and such)?" which turns on SCSI without any of the card drivers. The above strategy, if extended properly, would allow novice users to get *something* which worked, more easily. More advanced users could then fiddle with settings they knew about, and experiment. Those who *really* know what they're up to can create a wholly customised setup by choosing "none of the above", right at the beginning. As for the language CML2 is written in, surely C would work just as well as Python if the config-ruleset file is in a known format. GCC is required for the kernel to build, I don't see why anything else should be required simply to configure it. -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi@cyberspace.org (not for attachments) big-mail: chromatix@penguinpowered.com uni-mail: j.d.morton@lancaster.ac.uk The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -----BEGIN GEEK CODE BLOCK----- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -----END GEEK CODE BLOCK----- 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, 18 May 2001 12:04:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:04:15 -0400 Received: from galba.tp1.ruhr-uni-bochum.de ([134.147.240.75]:30217 "EHLO galba.tp1.ruhr-uni-bochum.de") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 12:04:02 -0400 Date: Fri, 18 May 2001 18:02:16 +0200 (CEST) From: Kai Germaschewski To: "Eric S. Raymond" cc: Alan Cox , Tom Rini , Michael Meissner , Keith Owens , CML2 , Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010518105353.A13684@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 May 2001, Eric S. Raymond wrote: > That being the case, we do face a question of design > philosophy, expressed as a policy question about how to design > rulesets. Actually two questions: > > 1. When we have a platform symbol for a reference design like MVME147, do > we stick to its spec sheet or consider it representative of all derivatives > (which may have other facilities)? > > I know my answer to this one, which I will implement unless there's > strong consensus otherwise. I go for explicitness. If we're going to > support MVME147 derivatives and variants in the ruleset, they get > their own platform symbols. I believe it's important two distinguish between two things here, auto-configuration and normal configuration. One should take care to not mix these things up. Of course I don't know about the specific hardware there, but I believe selecting NVME147 will give you arch specific code which will cope with general aspects of that board, but also for derived designs. That makes sense, and no need to introduce different config symbols at that level. I'd call CONFIG symbols like that basic, and they should be described by a ruleset which ensures that building the kernel will actually work, and that you have a chance that it even runs. (Things like a SCSI driver requires the SCSI midlayer, etc. which would normally lead to unresolved symbols or the inability to load the driver module into the running kernel later). On the other hand, for some people it would be nice to say I've got the reference board, build the right kernel. That's okay, but it should be another option, and rules like that should be in a separate files, so they don't clutter up the "basic" rulesets. So, leave the flexibility to people who need, and on top of that you can have a mechanism which allows easier configuration for people who don't want to care about the details. However, more important there would be some option like "build me a kernel for the hardware I'm currently running on" (and let the user fine tune afterwards). --Kai From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 12:00:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:00:03 -0400 Received: from ns.caldera.de ([212.34.180.1]:49793 "EHLO ns.caldera.de") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:59:57 -0400 Date: Fri, 18 May 2001 17:58:43 +0200 From: Christoph Hellwig To: John Cowan Cc: Jes Sorensen , esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518175843.A9347@caldera.de> Mail-Followup-To: Christoph Hellwig , John Cowan , Jes Sorensen , esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> <3B054500.2090408@reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B054500.2090408@reutershealth.com>; from jcowan@reutershealth.com on Fri, May 18, 2001 at 11:51:28AM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote: > Jes Sorensen wrote: > > > Telling them to install an updated gcc for kernel compilation > > is a necessary evil, which can easily be done without disturbing the > > rest of the system. Updating the system's python installation is not a > > reasonable request. > > > Au contraire. It is very reasonable to have both python and python2 > installed. Having two different gcc versions installed is a big pain > in the arse. Fump. Some distributions do even come with two gcc's out of the box. With the whole egcs and gcc2.95 (dunno about 3.0) you can even share the compiler driver if you want. Christoph -- Of course it doesn't work. We've performed a software upgrade. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 12:00:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:00:03 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:59400 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 11:59:58 -0400 Date: Fri, 18 May 2001 11:58:39 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518115839.E14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <1694.990198581@ocs3.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, May 18, 2001 at 04:39:57PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > > In general this is the best option, if you create a non-standard > > configuration for machine foo then it is your problem, not everybody > > else's. > > Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets > this whole discussion wouldn't be needed. I think you're confusing a couple of different issues here, Alan. Even supposing CML2 could parse CML1 rulesets, the design question about how configuration *should* work (that is, what kind of user experience we want to create and who we optimize ruleset design for) wouldn't go away. I'm raising these questions now because CML2's capabilities invite thinking about them. But they're independent of the underlying language. -- Eric S. Raymond To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long 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, 18 May 2001 12:05:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:05:43 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:41741 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 12:05:31 -0400 Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up To: esr@thyrsus.com Date: Fri, 18 May 2001 17:01:57 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), kaos@ocs.com.au (Keith Owens), linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518115839.E14309@thyrsus.com> from "Eric S. Raymond" at May 18, 2001 11:58:39 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > I think you're confusing a couple of different issues here, Alan. Even > supposing CML2 could parse CML1 rulesets, the design question about how > configuration *should* work (that is, what kind of user experience we > want to create and who we optimize ruleset design for) wouldn't go away. It would. Because people who like the old config would continue to use the old tools Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 12:06:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:06:03 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:61704 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 12:06:02 -0400 Date: Fri, 18 May 2001 12:04:34 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518120434.F14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518105353.A13684@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, May 18, 2001 at 04:38:08PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > > I don't want to do (a); it conflicts with my design objective of > > simplifying configuration enough that Aunt Tillie can do it. I won't > > do that unless I see a strong consensus that it's the only Right Thing. > > Its a good way of getting the defaults right. It may also be an appropriate > way of guiding presentation (eg putting the stuff the ruleset says you wont > have under a subcategory so you would see > > > CPU type > Devices > blah > blah > Other Options > IDE disk > Cardbus I want to understand what you're driving at here and I don't get it. What's the referent of "Its"? Are you saying you think Aunt Tillie's view of the world should guide the presentation of options? -- Eric S. Raymond Are we at last brought to such a humiliating and debasing degradation, that we cannot be trusted with arms for our own defence? Where is the difference between having our arms in our own possession and under our own direction, and having them under the management of Congress? If our defence be the *real* object of having those arms, in whose hands can they be trusted with more propriety, or equal safety to us, as in our own hands? -- Patrick Henry, speech of June 9 1788 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, 18 May 2001 12:16:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:16:33 -0400 Received: from t2.redhat.com ([199.183.24.243]:13820 "HELO executor.cambridge.redhat.com") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 12:16:27 -0400 Message-ID: <3B054AD6.7EB1582D@redhat.com> Date: Fri, 18 May 2001 17:16:22 +0100 From: Arjan van de Ven Reply-To: arjanv@redhat.com Organization: Red Hat, Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Eric S. Raymond" , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Eric S. Raymond" wrote: > > Arjan van de Ven : > > Don't get me wrong. I'm NOT opposed to having a config tool everyone and > > their aunt can use. I'm opposed to that tool taking away the options expert > > users have to do what they know is right for them. > > I'll take that as a vote for (b), to handle even perverse configurations > even if it means adding a lot of complexity to the ruleset. In my opinion, no configuration that is actually physically possible is perverse. So if you go for (a) you can take this as a vote of NOOOOOO PLEASE LINUS DON'T 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, 18 May 2001 12:10:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:10:43 -0400 Received: from hog.ctrl-c.liu.se ([130.236.252.129]:29194 "HELO hog.ctrl-c.liu.se") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 12:10:33 -0400 To: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Newsgroups: linux.kernel In-Reply-To: In-Reply-To: <20010518105353.A13684@thyrsus.com> Message-Id: <20010518155415.4A57F36DDC@hog.ctrl-c.liu.se> Date: Fri, 18 May 2001 17:54:15 +0200 (CEST) From: wingel@hog.ctrl-c.liu.se (Christer Weinigel) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox wrote: >At most it bounds the busses directly available. I've yet to see VME cardbus >adapters but its quite possible. You didn't try google did you? *grin* http://www.ramix.com/products/busadapters/rm235m.html /Christer -- "Just how much can I get away with and still go to heaven?" From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 12:12:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:12:13 -0400 Received: from ns.caldera.de ([212.34.180.1]:1922 "EHLO ns.caldera.de") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 12:11:57 -0400 Date: Fri, 18 May 2001 18:09:09 +0200 From: Christoph Hellwig To: "Eric S. Raymond" , Alan Cox , Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518180909.A10357@caldera.de> Mail-Followup-To: Christoph Hellwig , "Eric S. Raymond" , Alan Cox , Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518105353.A13684@thyrsus.com> <20010518120434.F14309@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: <20010518120434.F14309@thyrsus.com>; from esr@thyrsus.com on Fri, May 18, 2001 at 12:04:34PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote: > Alan Cox : > > > I don't want to do (a); it conflicts with my design objective of > > > simplifying configuration enough that Aunt Tillie can do it. I won't > > > do that unless I see a strong consensus that it's the only Right Thing. > > > > Its a good way of getting the defaults right. It may also be an appropriate > > way of guiding presentation (eg putting the stuff the ruleset says you wont > > have under a subcategory so you would see > > > > > > CPU type > > Devices > > blah > > blah > > Other Options > > IDE disk > > Cardbus > > I want to understand what you're driving at here and I don't get it. What's > the referent of "Its"? Are you saying you think Aunt Tillie's view of the > world should guide the presentation of options? Aunt Tillie shouldn't try to manually configure a kernel. Christoph P.S. _please_ shorten your .sig -- Whip me. Beat me. Make me maintain AIX. 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, 18 May 2001 12:23:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:23:43 -0400 Received: from spc.esa.lanl.gov ([128.165.46.232]:15242 "HELO spc.esa.lanl.gov") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 12:23:31 -0400 Content-Type: text/plain; charset=US-ASCII From: Steven Cole Reply-To: scole@lanl.gov To: Jes Sorensen , esr@thyrsus.com Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Date: Fri, 18 May 2001 10:22:33 -0600 X-Mailer: KMail [version 1.2] Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010515173316.A8308@thyrsus.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <0105181022330G.10237@spc.esa.lanl.gov> Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Friday 18 May 2001 09:19, Jes Sorensen wrote: > Replacing the code does not require changing the style of the config > files. Thats a major problem with CML2, you introduce a new 'let me do > everything for you' tool that relies on a programming language that is > not being shipped by any major vendor nor does it look like they are > planning to do it anytime soon. And even if they start doing so, this Actually, Linux-Mandrake 8.0 ships with Python 2.0, but your next point is a very good one: > is a totally unreasonable requirement, you *must* to make it possible > to compile kernels on older distributions without requiring people to > update half of their system. On some architectures, the majority of > the users are still on glibc 2.0 and other old versions of > tools. Telling them to install an updated gcc for kernel compilation > is a necessary evil, which can easily be done without disturbing the > rest of the system. Updating the system's python installation is not a > reasonable request. Nobody disagrees that the Makefiles needs a > redesign, however that doesn't mean everything else has to be > redisigned in a totally incompatible manner. I didn't have trouble installing python 2.0 before LM 8.0 did that for me, but I was probably just lucky. I've seen some reports by other people who did have difficulty upgrading python. If the python installation difficulties are a real obstacle, perhaps that is what needs to be fixed. Steven 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, 18 May 2001 12:19:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:19:13 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:64520 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 12:18:53 -0400 Date: Fri, 18 May 2001 12:17:15 -0400 From: "Eric S. Raymond" To: Jonathan Morton Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518121715.H14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Jonathan Morton , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <3B053B9B.23286E6C@redhat.com>; <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from chromi@cyberspace.org on Fri, May 18, 2001 at 04:59:47PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jonathan Morton : > Not everyone falls into the "expert user" and "Aunt Tillie" categories. > It's a *very* big grey area. If some semi-computer-literate user (ie. some > friends of mine!) wants to upgrade their kernel so they have access to > newer hardware (such as a cheap USB webcam), it should be made as simple as > possible for them. CML1 doesn't handle that very well, I'd like to see > it's replacement do better. Yes. One of the reasons I keep Aunt Tillie in mind as a UI target is that if I can design a configuration system that makes the task possible for her, then I'll have one that makes it easy for this much larger class of intermediate-level users. -- Eric S. Raymond In the absence of any evidence tending to show that possession or use of a 'shotgun having a barrel of less than eighteen inches in length' at this time has some reasonable relationship to the preservation or efficiency of a well regulated militia, we cannot say that the Second Amendment guarantees the right to keep and bear such an instrument. [...] The Militia comprised all males physically capable of acting in concert for the common defense. -- Majority Supreme Court opinion in "U.S. vs. Miller" (1939) 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, 18 May 2001 12:35:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:35:45 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:2569 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 12:35:34 -0400 Date: Fri, 18 May 2001 12:34:13 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518123413.I14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518115839.E14309@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, May 18, 2001 at 05:01:57PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > > I think you're confusing a couple of different issues here, Alan. Even > > supposing CML2 could parse CML1 rulesets, the design question about how > > configuration *should* work (that is, what kind of user experience we > > want to create and who we optimize ruleset design for) wouldn't go away. > > It would. Because people who like the old config would continue to use the > old tools Excuse me? Alan, it sounds very much like you just said something stupid. This seems sufficiently unlikely that I am shaking my head in disbelief and fingernailing wax out of both ears (and if you think doing both those things at once is easy try it sometime :-)). Do you really believe that anyone is going to maintain the CML1 tools for as long as a nanosecond after they get dropped out of the kernel tree? Even supposing somebody were loony enough to do that, how would preserving an old interface in amber do anything to explore new UI possibilities? Perhaps I'm just unusually dense this morning. -- Eric S. Raymond Alcohol still kills more people every year than all `illegal' drugs put together, and Prohibition only made it worse. Oppose the War On Some Drugs! 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, 18 May 2001 12:46:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:45:58 -0400 Received: from t2.redhat.com ([199.183.24.243]:26108 "HELO executor.cambridge.redhat.com") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 12:45:48 -0400 Message-ID: <3B0551B4.CB251F64@redhat.com> Date: Fri, 18 May 2001 17:45:40 +0100 From: Arjan van de Ven Reply-To: arjanv@redhat.com Organization: Red Hat, Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Eric S. Raymond" , linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010518115839.E14309@thyrsus.com> <20010518123413.I14309@thyrsus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Eric S. Raymond" wrote: > > It would. Because people who like the old config would continue to use the > > old tools > > Excuse me? > Do you really believe that anyone is going to maintain the CML1 tools > for as long as a nanosecond after they get dropped out of the kernel tree? I hereby volunteer to maintain at least make oldconfig and make config, and perhaps make menuconfig. > Even supposing somebody were loony enough to do that, how would preserving > an old interface in amber do anything to explore new UI possibilities? kernel != GUI There are plenty of UI kernel configurators out there. Good ones. Bad ones. LOOK AT THEM. FIX THEM if you don't like them. But PLEASE don't even think about taking the current, very useful for advanced users, tools away without offering something of at least the same capabilities. > Perhaps I'm just unusually dense this morning. Given the rest of this thread, unusual is not the word that comes to my mind (sorry, open door and you asked for it) 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, 18 May 2001 12:44:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 12:44:48 -0400 Received: from ns.caldera.de ([212.34.180.1]:15746 "EHLO ns.caldera.de") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 12:44:37 -0400 Date: Fri, 18 May 2001 18:43:10 +0200 From: Christoph Hellwig To: "Eric S. Raymond" , Alan Cox , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518184310.A14113@caldera.de> Mail-Followup-To: Christoph Hellwig , "Eric S. Raymond" , Alan Cox , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518115839.E14309@thyrsus.com> <20010518123413.I14309@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: <20010518123413.I14309@thyrsus.com>; from esr@thyrsus.com on Fri, May 18, 2001 at 12:34:13PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: > Alan, it sounds very much like you just said something stupid. This > seems sufficiently unlikely that I am shaking my head in disbelief and > fingernailing wax out of both ears (and if you think doing both those > things at once is easy try it sometime :-)). > > Do you really believe that anyone is going to maintain the CML1 tools > for as long as a nanosecond after they get dropped out of the kernel tree? I _will_ continue to maintain mconfig (after mec stopped even before cml2). Christoph -- Of course it doesn't work. We've performed a software upgrade. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 13:03:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:02:58 -0400 Received: from munchkin.spectacle-pond.org ([209.192.197.45]:60936 "EHLO munchkin.spectacle-pond.org") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:02:45 -0400 Date: Fri, 18 May 2001 12:43:55 -0400 From: Michael Meissner To: Christoph Hellwig , "Eric S. Raymond" , Alan Cox , Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518124355.A20191@munchkin.spectacle-pond.org> In-Reply-To: <20010518105353.A13684@thyrsus.com> <20010518120434.F14309@thyrsus.com> <20010518180909.A10357@caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010518180909.A10357@caldera.de>; from hch@ns.caldera.de on Fri, May 18, 2001 at 06:09:09PM +0200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel.... After all, all of us at one point in time were newbies in terms of configuring kernels, etc. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: meissner@redhat.com phone: +1 978-486-9304 Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482 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, 18 May 2001 13:07:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:07:22 -0400 Received: from fjordland.nl.linux.org ([131.211.28.101]:53000 "EHLO fjordland.nl.linux.org") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:07:07 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Arjan van de Ven , "Eric S. Raymond" , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Date: Fri, 18 May 2001 19:07:36 +0200 X-Mailer: KMail [version 1.2] In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> In-Reply-To: <3B053B9B.23286E6C@redhat.com> MIME-Version: 1.0 Message-Id: <01051819073604.00491@starship> Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Friday 18 May 2001 17:11, Arjan van de Ven wrote: > > (a) Back off the capability approach. That is, accept that > > people doing configuration are going to explicitly and > > exhaustively specify low-level hardware. > > > > > I don't want to do (a); it conflicts with my design objective of > > simplifying configuration enough that Aunt Tillie can do it. I > > won't do that unless I see a strong consensus that it's the only > > Right Thing. > > Aunt Tillie doesn't even know what a kernel is, nor does she want to. A little presumptuous, no? I do in fact know an 'Aunt Tillie' type who configures her own kernel. When she gets stuck she calls for help from her son, who is a computer geek. > I think it's fair to assume that people who configure and compile their own > kernel (as opposed to using the distribution supplied ones) know what they > are doing. Not a fair assumption, if only because everybody does it for the first time. > Or at least make something like a "Expert level" question as first question, so > that people who DO know what they are doing can select the options they want. Yes. The hackneyed platitude that 'easy' and 'powerful' are mutually exclusive is a statistical observation, not a law of the universe. -- Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 13:05:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:05:48 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:11017 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:05:31 -0400 Date: Fri, 18 May 2001 13:04:28 -0400 From: "Eric S. Raymond" To: Arjan van de Ven Cc: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518130428.M14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <3B054AD6.7EB1582D@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B054AD6.7EB1582D@redhat.com>; from arjanv@redhat.com on Fri, May 18, 2001 at 05:16:22PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Arjan van de Ven : > In my opinion, no configuration that is actually physically possible > is perverse. Noted. And a very pithy statement of the position. Thanks. -- Eric S. Raymond I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 13:11:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:11:38 -0400 Received: from fw-cam.cambridge.arm.com ([193.131.176.3]:17067 "EHLO fw-cam.cambridge.arm.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:11:26 -0400 Message-Id: <4.3.2.7.2.20010518175230.0253e040@cam-pop.cambridge.arm.com> X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 May 2001 18:10:20 +0100 To: From: Ruth Ivimey-Cook Subject: Re: CML2 design philosophy heads-up In-Reply-To: In-Reply-To: <"Eric S. Raymond"'s message of "Sat, 5 May 2001 19:27:31 -0400"> <20010505192731.A2374@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At 04:22 PM 5/13/01 +0200, you wrote: >I've said before on these lists that one of the purposes of >CML2's single-apex tree design is to move the configuration >dialog away from low-level platform- specific questions towards >higher-level questions about policy or intentions. > >Or to put another way: away from hardware, towards capabilities. Can I just say I think this is the right approach, overall. Those who say it's not right to cripple those doing weird things to support the masses are right, but on the other hand very many kernel compiles will be relatively small deviations from a fairly standard setup (e.g. enabling or disabling NAT) and in my opinion life's too short to spend learning about configuring the latest kernel. Specifically: 1. Deriving common cases from simple assertions is Good for many people, making it less likely they will end up with a bad kernel through oversight. 2. Allowing an expert mode that allows you to change each & every option allows those with specific needs to configure them (i.e. you need know whether a user made a choice to include X rather than it being a derivation, and this must be stored in the config database along with the actual choice) 3. I would like to be able to start off configuring a kernel with a list of statements like: - an Asus motherboard - a Pentium III - an Adaptec AHA2400 SCSI controller - IDE disks and see what else must be specified. I.e. I don't want to have to search to tell the config program what I know; I want to tell it what I know, digest that and then let it figure out what else it needs answers to. -- extra bonus section: Obviously, sometimes, you are compiling for another machine, but it would be great if the config could be asked to get at least some of this list of items from the current hardware/system (using lspci and friends). It would be nice if it then printed a summary (in English, not config-ese) what has been configured, so I can double-check. 4. It would be neat to have a quick way of taking a config file from an older kernel. Then the config program to be able to tell what config items have changed/are new/etc and then have a menu containing just these items. You could then upgrade kernels by looking through this list, safe in the knowledge that everything else is already OK. 5. One final, general plea: Please can we have a sensible menu structure for the config options. The current (for me, 2.4.1) menu structure is just plain irritating, because it is not organised in an understandable (for me) way... If you want me to help define things further, I'm willing. HTH, Ruth -- Ruth Ivimey-Cook ruthc@sharra.demon.co.uk Technical Author, ARM Ltd ruth.ivimey-cook@arm.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 13:13:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:13:19 -0400 Received: from t2.redhat.com ([199.183.24.243]:34044 "HELO executor.cambridge.redhat.com") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 13:13:10 -0400 Message-ID: <3B05581D.BBE089A3@redhat.com> Date: Fri, 18 May 2001 18:13:01 +0100 From: Arjan van de Ven Reply-To: arjanv@redhat.com Organization: Red Hat, Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Meissner , linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010518105353.A13684@thyrsus.com> <20010518120434.F14309@thyrsus.com> <20010518180909.A10357@caldera.de> <20010518124355.A20191@munchkin.spectacle-pond.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Michael Meissner wrote: > > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > > Aunt Tillie shouldn't try to manually configure a kernel. > > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel.... After > all, all of us at one point in time were newbies in terms of configuring And maybe she uses KDE and clicks kkernelconfigurator for the first steps. And if she wants to learn, she even might stumble on the HOWTO.. 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, 18 May 2001 13:15:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:15:48 -0400 Received: from marine.sonic.net ([208.201.224.37]:21538 "HELO marine.sonic.net") by vger.kernel.org with SMTP id ; Fri, 18 May 2001 13:15:37 -0400 X-envelope-info: Date: Fri, 18 May 2001 10:15:33 -0700 From: Mike Castle To: linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518101533.E10611@thune.mrc-home.com> Reply-To: Mike Castle Mail-Followup-To: Mike Castle , linux-kernel@vger.kernel.org In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> <3B054500.2090408@reutershealth.com> <20010518175843.A9347@caldera.de> <3B05473B.70606@reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.6i In-Reply-To: <3B05473B.70606@reutershealth.com>; from jcowan@reutershealth.com on Fri, May 18, 2001 at 12:00:59PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote: > Christoph Hellwig wrote: > Yes, I should have limited myself to pre-egcs versions. Huh? It's been possible to have multiple versions of gcc installed for a very long time. At least since 2.0 came out. Thu Dec 19 15:54:29 1991 K. Richard Pixley (rich at cygnus.com) * configure: added -V for version number option. mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen 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, 18 May 2001 13:18:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:18:28 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:12553 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:18:10 -0400 Date: Fri, 18 May 2001 13:17:07 -0400 From: "Eric S. Raymond" To: Arjan van de Ven Cc: linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518131707.N14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010518115839.E14309@thyrsus.com> <20010518123413.I14309@thyrsus.com> <3B0551B4.CB251F64@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B0551B4.CB251F64@redhat.com>; from arjanv@redhat.com on Fri, May 18, 2001 at 05:45:40PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Arjan van de Ven : > I hereby volunteer to maintain at least make oldconfig and make config, > and perhaps make menuconfig. That's the easy part; the CML1 config code may be ugly and broken, but at least it's relatively stable. What you'd also have to do is maintain an entire CML1 ruleset in parallel with the canonical CML2 one. That's the hard part. I've been keeping the CML2 ruleset synced with CML1 for a year now. It's been an ugly, nasty, horrible job -- *much* nastier, by an order of magnitude, than designing and writing the CML2 engine. Going the other direction would be worse. "Like chewing razor blades" is the simile that leaps to mind. (And no, dropping back to CML1 format for the masters wouldn't be an option; it doesn't have the semantic strength to enable CML2's new capabilities.) -- Eric S. Raymond Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960 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, 18 May 2001 13:22:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:22:38 -0400 Received: from nat-pool-meridian.redhat.com ([199.183.24.200]:9808 "EHLO devserv.devel.redhat.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:22:28 -0400 Date: Fri, 18 May 2001 13:22:27 -0400 From: Arjan van de Ven To: "Eric S. Raymond" , Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518132227.A24701@devserv.devel.redhat.com> In-Reply-To: <20010518115839.E14309@thyrsus.com> <20010518123413.I14309@thyrsus.com> <3B0551B4.CB251F64@redhat.com> <20010518131707.N14309@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: <20010518131707.N14309@thyrsus.com>; from esr@thyrsus.com on Fri, May 18, 2001 at 01:17:07PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2001 at 01:17:07PM -0400, Eric S. Raymond wrote: > It's been an ugly, nasty, horrible job -- *much* nastier, by an order > of magnitude, than designing and writing the CML2 engine. Going the > other direction would be worse. "Like chewing razor blades" is the > simile that leaps to mind. And you hope this will not be razorblades if Linus decides he likes CML2 ? > (And no, dropping back to CML1 format for the masters wouldn't be an > option; it doesn't have the semantic strength to enable CML2's new > capabilities.) Right now, it's now a dropping back. You seem to take for granted that CML2 and your python2 frontend to it are 2.5.0 material. I don't right now. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 13:24:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:24:18 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:15369 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:24:07 -0400 Date: Fri, 18 May 2001 13:22:35 -0400 From: "Eric S. Raymond" To: Michael Meissner Cc: Christoph Hellwig , Alan Cox , Tom Rini , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518132235.O14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Michael Meissner , Christoph Hellwig , Alan Cox , Tom Rini , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518105353.A13684@thyrsus.com> <20010518120434.F14309@thyrsus.com> <20010518180909.A10357@caldera.de> <20010518124355.A20191@munchkin.spectacle-pond.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010518124355.A20191@munchkin.spectacle-pond.org>; from meissner@spectacle-pond.org on Fri, May 18, 2001 at 12:43:55PM -0400 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 Michael Meissner : > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > > Aunt Tillie shouldn't try to manually configure a kernel. > > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel.... After > all, all of us at one point in time were newbies in terms of configuring > kernels, etc. And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know, the one with the unicorn appliques and the pink scrunchies and the Back Street Boys posters in her bedroom? Dammit, if we're serious about empowering people with free software we can't limit ourselves with the attitude that configuring kernels (or anything else) is the sacred preserve of a geek elite. -- Eric S. Raymond The price of liberty is, always has been, and always will be blood. The person who is not willing to die for his liberty has already lost it to the first scoundrel who is willing to risk dying to violate that person's liberty. Are you free? -- Andrew Ford 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, 18 May 2001 13:26:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:26:18 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:16649 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:26:10 -0400 Date: Fri, 18 May 2001 13:25:07 -0400 From: "Eric S. Raymond" To: Arjan van de Ven Cc: linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518132507.P14309@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010518115839.E14309@thyrsus.com> <20010518123413.I14309@thyrsus.com> <3B0551B4.CB251F64@redhat.com> <20010518131707.N14309@thyrsus.com> <20010518132227.A24701@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010518132227.A24701@devserv.devel.redhat.com>; from arjanv@redhat.com on Fri, May 18, 2001 at 01:22:27PM -0400 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 Arjan van de Ven : > Right now, it's now a dropping back. You seem to take for granted that CML2 > and your python2 frontend to it are 2.5.0 material. I don't right now. Linus is free to change his mind. Perhaps he will. But the last word I heard from him is that CML2 goes in in the 2.5.1-2.5.2 timeframe. That's the assumption I'm operating on. -- Eric S. Raymond An armed society is a polite society. Manners are good when one may have to back up his acts with his life. -- Robert A. Heinlein, "Beyond This Horizon", 1942 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, 18 May 2001 13:28:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:28:48 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:23310 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:28:39 -0400 Subject: Re: CML2 design philosophy heads-up To: esr@thyrsus.com Date: Fri, 18 May 2001 18:23:55 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), trini@kernel.crashing.org (Tom Rini), meissner@spectacle-pond.org (Michael Meissner), kaos@ocs.com.au (Keith Owens), linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518120434.F14309@thyrsus.com> from "Eric S. Raymond" at May 18, 2001 12:04:34 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > I want to understand what you're driving at here and I don't get it. What's What I am trying to say is that if you can infer probable configuration categories that are relevant then instead of automatically filling the other areas in and blocking changing them without using vi you can put the other options as a submenu. That guides the less expert user and also helps rather than hinders the expert 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, 18 May 2001 13:28:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:28:38 -0400 Received: from ns.caldera.de ([212.34.180.1]:46210 "EHLO ns.caldera.de") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:28:33 -0400 Date: Fri, 18 May 2001 19:28:21 +0200 Message-Id: <200105181728.f4IHSLP19357@ns.caldera.de> From: hch@caldera.de (Christoph Hellwig) To: dalgoda@ix.netcom.com (Mike Castle) Cc: linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up X-Newsgroups: caldera.lists.linux.kernel In-Reply-To: <20010518101533.E10611@thune.mrc-home.com> User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.2 (i686)) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In article <20010518101533.E10611@thune.mrc-home.com> you wrote: > On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote: >> Christoph Hellwig wrote: [my voice was snipped here] >> Yes, I should have limited myself to pre-egcs versions. > > Huh? > > It's been possible to have multiple versions of gcc installed for a very > long time. At least since 2.0 came out. > > Thu Dec 19 15:54:29 1991 K. Richard Pixley (rich at cygnus.com) > > * configure: added -V for version number option. But with at least the combination of gcc2.7.2.x and egcs1.x it did not work for me (and others). Christoph -- Whip me. Beat me. Make me maintain AIX. 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, 18 May 2001 13:35:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:35:38 -0400 Received: from www.wen-online.de ([212.223.88.39]:26638 "EHLO wen-online.de") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:35:34 -0400 Date: Fri, 18 May 2001 19:35:07 +0200 (CEST) From: Mike Galbraith X-X-Sender: To: Jonathan Morton cc: , Arjan van de Ven , Subject: Re: CML2 design philosophy heads-up In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 May 2001, Jonathan Morton wrote: > As for the language CML2 is written in, surely C would work just as well as > Python if the config-ruleset file is in a known format. GCC is required > for the kernel to build, I don't see why anything else should be required > simply to configure it. Menuconfig is fairly popular, and requires curses.. etc. etc. There isn't a configurator which doesn't require something more than gcc is there? OTOH, python here says: Python 1.3 (Dec 19 1995) [GCC 2.7.2]. I didn't have it built at all during the years prior to 1995, so I'm sure you can imagine how enthusiastic I am about upgrading that old turd ;-) -Mike 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, 18 May 2001 13:37:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:37:08 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:28942 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:36:53 -0400 Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up To: esr@thyrsus.com Date: Fri, 18 May 2001 18:33:15 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), kaos@ocs.com.au (Keith Owens), linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518123413.I14309@thyrsus.com> from "Eric S. Raymond" at May 18, 2001 12:34:13 PM X-Mailer: ELM [version 2.5 PL3] 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 > Do you really believe that anyone is going to maintain the CML1 tools > for as long as a nanosecond after they get dropped out of the kernel tree? Do you really believe anyone would be dumb enough to delete them out of spite or to further your political machinations if they could both handle the same configuration language. CML1 has had no official maintainer for about 4 years. People contribute bits and it works. So as it stands there would be no reason to remove it. 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, 18 May 2001 13:42:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:42:38 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:20745 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:42:31 -0400 Date: Fri, 18 May 2001 13:41:04 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up Message-ID: <20010518134104.A16093@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518120434.F14309@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, May 18, 2001 at 06:23:55PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > What I am trying to say is that if you can infer probable configuration > categories that are relevant then instead of automatically filling the other > areas in and blocking changing them without using vi you can put the other > options as a submenu. That guides the less expert user and also helps rather > than hinders the expert OK, that's useful input. Noted. There's a bit of a technical problem with the distinction between derivations (which are like macros) and question symbols (which can be suppressed or unsuppressed depending on their visibility predicate But perhaps I can think up a solution to that one over lunch. -- Eric S. Raymond You [should] not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harm it would cause if improperly administered -- Lyndon Johnson, former President of the U.S. 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, 18 May 2001 13:45:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:45:09 -0400 Received: from ns.caldera.de ([212.34.180.1]:59778 "EHLO ns.caldera.de") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:44:56 -0400 Date: Fri, 18 May 2001 19:42:25 +0200 From: Christoph Hellwig To: "Eric S. Raymond" , Michael Meissner , Alan Cox , Tom Rini , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518194225.A20327@caldera.de> Mail-Followup-To: Christoph Hellwig , "Eric S. Raymond" , Michael Meissner , Alan Cox , Tom Rini , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518105353.A13684@thyrsus.com> <20010518120434.F14309@thyrsus.com> <20010518180909.A10357@caldera.de> <20010518124355.A20191@munchkin.spectacle-pond.org> <20010518132235.O14309@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: <20010518132235.O14309@thyrsus.com>; from esr@thyrsus.com on Fri, May 18, 2001 at 01:22:35PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote: > Michael Meissner : > > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > > > Aunt Tillie shouldn't try to manually configure a kernel. > > > > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel.... After > > all, all of us at one point in time were newbies in terms of configuring > > kernels, etc. > > And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know, > the one with the unicorn appliques and the pink scrunchies and the Back Street > Boys posters in her bedroom? That's ok as long as she doesn't add backstreet boys songtexts as long as your signature to her mails. On the other hand she should _really_ learn how to do it - like we all did. > Dammit, if we're serious about empowering people with free software we can't > limit ourselves with the attitude that configuring kernels (or anything > else) is the sacred preserve of a geek elite. I see _no_ reason to give up my control for people with an attitude that configuring kernels will not need knowledge of what one is doing. Your point is basically: Lets rewrite the kernel in VBA to make every word user capable of driver hacking. That doesn't work. Christoph -- Auch der Dumme hat manchmal einen gescheiten Gedanken. Er merkt es nur nicht. -- Danny Kaye 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, 18 May 2001 13:47:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 13:47:49 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:35342 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 13:47:32 -0400 Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up To: hch@caldera.de (Christoph Hellwig) Date: Fri, 18 May 2001 18:42:39 +0100 (BST) Cc: esr@thyrsus.com (Eric S. Raymond), meissner@spectacle-pond.org (Michael Meissner), alan@lxorguk.ukuu.org.uk (Alan Cox), trini@kernel.crashing.org (Tom Rini), kaos@ocs.com.au (Keith Owens), linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518194225.A20327@caldera.de> from "Christoph Hellwig" at May 18, 2001 07:42:25 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > That's ok as long as she doesn't add backstreet boys songtexts as long as your > signature to her mails. I wouldn't worry. She'd be swimming to Cuba in search of asylum from the MPAA if she did > Your point is basically: > Lets rewrite the kernel in VBA to make every word user > capable of driver hacking. I think thats a bit unfair. Changing the description language so drastically is the big problem, not the tools or its UI. Its 'and Im forking the config language from under every other config tool including the kde work and mconfig' 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, 18 May 2001 14:26:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 14:26:41 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:26633 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 14:26:29 -0400 Date: Fri, 18 May 2001 14:25:08 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518142508.B16093@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518123413.I14309@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, May 18, 2001 at 06:33:15PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > Do you really believe anyone would be dumb enough to delete them out of spite > or to further your political machinations if they could both handle the same > configuration language. That's a big "if" which I don't think is ever going to happen. The CML1 and CML2 languages are nowhere near semantically equivalent. I know them both intimately, and bridging the gap is a much harder problem than you seem prepared to realize. They look closer together than they are, because you can superficially map individual features between them (CML2 derivations look like CML1 defines, for example). The big difference is subtler, and has to do with the difference between a control language and a constraint language. As a result, there are things you can easily do in CML2 that you can't practically speaking do in CML1. For CML1 and CML2 to handle the same language, we would either have to live with the CML1 language's limitations or retrofit the old tools to speak CML2 language. The chance of the latter happening is, I think we can agree, effectively zero. I know you've talked about parsing CML1 into constraints with backtracking. Maybe you're smart enough to do that. I'm not. I tried that route early on. I predict that if you do, you'll experience a great deal of suffering, acquire a valuable education, and get no good result. -- Eric S. Raymond The common argument that crime is caused by poverty is a kind of slander on the poor. -- H. L. Mencken 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, 18 May 2001 14:31:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 14:31:21 -0400 Received: from mail.reutershealth.com ([204.243.9.36]:24262 "EHLO mail.reutershealth.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 14:31:17 -0400 Message-ID: <3B0569D9.4040006@reutershealth.com> Date: Fri, 18 May 2001 14:28:41 -0400 From: John Cowan User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: "Eric S. Raymond" , Michael Meissner , Alan Cox , Tom Rini , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010518105353.A13684@thyrsus.com> <20010518120434.F14309@thyrsus.com> <20010518180909.A10357@caldera.de> <20010518124355.A20191@munchkin.spectacle-pond.org> <20010518132235.O14309@thyrsus.com> <20010518194225.A20327@caldera.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Christoph Hellwig wrote: > That's ok as long as she doesn't add backstreet boys songtexts as long as your > signature to her mails. In fact, they aren't so long once you cut out the repetitions. > On the other hand she should _really_ learn how to do it - like we all did. Hey, nothing stops you from buying a used front panel and toggling in Linux in octal. Oughta work the first time, too. -- There is / one art || John Cowan no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein 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, 18 May 2001 15:13:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 15:12:56 -0400 Received: from brussel-ns1.xs4all.be ([195.144.67.168]:11531 "EHLO brussel-ns1.xs4all.be") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 15:12:37 -0400 Date: Fri, 18 May 2001 21:12:07 +0200 (CEST) From: frank@gevaerts.be To: "Eric S. Raymond" cc: Tom Rini , Michael Meissner , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010518034307.A10784@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 May 2001, Eric S. Raymond wrote: > Tom Rini : > > > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid > > > > layer code but no SCSI hardware drivers. It is a realistic case for an > > > > embedded CD-RW appliance. > > > > > > Or alternatively, you want to enable SCSI code, with no hardware driver, > > > because you are going to build pcmcia, which builds the scsi drivers only > > > if CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or > > > 1480 scsi card into your pcmcia slot. > > > > Both of these 'problems' assume that you can have IDE or PCMCIA on these > > particular boxes. Does anyone know if that's actually true? > > The answer is: no, you can't. > > I found a feature list for the MVME147 on the web at > . It > confirmed what thought I remembered from the Motorola site; no PCMCIA, > no IDE/ATAPI. As a matter of fact neither of these technologies > existed yet when the board was being designed in the mid-1980s. But it is a VME board. That means you can put a SCSI controller on the VME bus (and these do exist, I have one right here). Frank > > (The article I found is kind of interesting. It's a dissection of the > MVME147's design and history...narrated in first person.) > > In any case, if this *had* been a problem, the right fix IMO would have > been to split the SCSI symbol into SCSI and SCSI_DRIVERS and have > constraints that would make SCSI and the presence of any SCSI card > imply SCSI_DRIVERS. > -- > Eric S. Raymond > > The prestige of government has undoubtedly been lowered considerably > by the Prohibition law. For nothing is more destructive of respect for > the government and the law of the land than passing laws which cannot > be enforced. It is an open secret that the dangerous increase of crime > in this country is closely connected with this. > -- Albert Einstein, "My First Impression of the U.S.A.", 1921 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > HI! I'm a .signature virus! cp me into your .signature file to help me spread! 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, 18 May 2001 15:13:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 15:12:56 -0400 Received: from smtp1.cern.ch ([137.138.128.38]:30984 "EHLO smtp1.cern.ch") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 15:12:43 -0400 To: Keith Owens Cc: CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: CML2 design philosophy heads-up In-Reply-To: <1694.990198581@ocs3.ocs-net> From: Jes Sorensen Date: 18 May 2001 21:12:34 +0200 In-Reply-To: Keith Owens's message of "Sat, 19 May 2001 01:09:41 +1000" Message-ID: User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 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 >>>>> "Keith" == Keith Owens writes: Keith> cc trimmed back to mailing lists only. On Fri, 18 May 2001 Keith> 10:53:53 -0400, "Eric S. Raymond" wrote: >> (a) Back off the capability approach. That is, accept that people >> doing configuration are going to explicitly and exhaustively >> specify low-level hardware. Keith> No, you loose one of the nicer features of CML2. No, explicit selection *must* be available as an option. 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 ; Fri, 18 May 2001 15:17:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 15:16:55 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:14607 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 15:16:39 -0400 Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up To: esr@thyrsus.com Date: Fri, 18 May 2001 20:13:04 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), kaos@ocs.com.au (Keith Owens), linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518142508.B16093@thyrsus.com> from "Eric S. Raymond" at May 18, 2001 02:25:08 PM X-Mailer: ELM [version 2.5 PL3] 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 > For CML1 and CML2 to handle the same language, we would either have > to live with the CML1 language's limitations or retrofit the old tools > to speak CML2 language. The chance of the latter happening is, I think > we can agree, effectively zero. Being able to turn CML2 into CML1 might be the more useful exercise. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 15:45:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 15:45:45 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:38153 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 15:45:28 -0400 Date: Fri, 18 May 2001 15:44:07 -0400 From: "Eric S. Raymond" To: Alan Cox Cc: Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518154407.C17324@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518142508.B16093@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, May 18, 2001 at 08:13:04PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > Being able to turn CML2 into CML1 might be the more useful exercise. That's...not a completely crazy idea. Hmmm... It might be possible to take a CML2 rulebase and generate a sort of stupid jackleg CML1 translation of it. The resulting config.in would be huge and nasty, and would only work in forward sequence with no side-effect computation, but you just might be able to get the old tools to parse it. Again there's a technical problem with derivations. Probably solvable. But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? -- 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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 May 2001 16:07:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 16:07:25 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:42767 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 16:07:13 -0400 Subject: Re: CML2 design philosophy heads-up To: mikeg@wen-online.de (Mike Galbraith) Date: Fri, 18 May 2001 21:03:31 +0100 (BST) Cc: chromi@cyberspace.org (Jonathan Morton), esr@thyrsus.com, arjanv@redhat.com (Arjan van de Ven), linux-kernel@vger.kernel.org In-Reply-To: from "Mike Galbraith" at May 18, 2001 07:35:07 PM X-Mailer: ELM [version 2.5 PL3] 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 > Menuconfig is fairly popular, and requires curses.. etc. etc. There isn't > a configurator which doesn't require something more than gcc is there? Configure only requires shell 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, 18 May 2001 16:41:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 16:41:50 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:59407 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 16:41:38 -0400 Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up To: esr@thyrsus.com Date: Fri, 18 May 2001 21:38:04 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), kaos@ocs.com.au (Keith Owens), linux-kernel@vger.kernel.org (CML2), kbuild-devel@lists.sourceforge.net In-Reply-To: <20010518154407.C17324@thyrsus.com> from "Eric S. Raymond" at May 18, 2001 03:44:07 PM X-Mailer: ELM [version 2.5 PL3] 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 > But the real question is whether the old tools have enough value to be > worth the effort. What problem are you trying to solve here? Im just playing with ideas and writing a CML1 parser for amusement while I ponder single pass computation of the entire dependancy graph from a CML1 rule base 8) 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, 18 May 2001 21:50:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 21:50:26 -0400 Received: from vitelus.com ([64.81.36.147]:28937 "EHLO vitelus.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 21:50:18 -0400 Date: Fri, 18 May 2001 18:49:58 -0700 From: Aaron Lehmann To: "Eric S. Raymond" , Alan Cox , Keith Owens , CML2 , kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010518184957.A6949@vitelus.com> In-Reply-To: <20010518115839.E14309@thyrsus.com> <20010518123413.I14309@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010518123413.I14309@thyrsus.com>; from esr@thyrsus.com on Fri, May 18, 2001 at 12:34:13PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: > Even supposing somebody were loony enough to do that, how would preserving > an old interface in amber do anything to explore new UI possibilities? I don't know about the rest of the world, but I _much_ prefer the old menuconfig to CML2's menuconfig. While I haven't spent much time playing with CML2, I'm familiar with cml1's tools and see no reason why they need changes, which IMHO (so far) are detrimental. That's not even to mention python issues, speed, or anything else. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 19 May 2001 01:47:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 19 May 2001 01:47:27 -0400 Received: from james.kalifornia.com ([208.179.59.2]:63068 "EHLO james.kalifornia.com") by vger.kernel.org with ESMTP id ; Sat, 19 May 2001 01:47:15 -0400 Message-ID: <3B06082E.9090708@kalifornia.com> Date: Fri, 18 May 2001 22:44:14 -0700 From: Ben Ford User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 To: Charles Cazabon CC: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518093414.A21164@qcc.sk.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Charles Cazabon wrote: >Eric S. Raymond wrote: > >>Arjan van de Ven : >> >>>Aunt Tillie doesn't even know what a kernel is, nor does she want >>>to. I think it's fair to assume that people who configure and >>>compile their own kernel (as opposed to using the distribution >>>supplied ones) know what they are doing. >>> >>I'd like to break these assumptions. Or at the very least see how far >>they can be bent. I know this sounds crazy to a lot of hackers, but >>I think there's a certain amount of unhelpful elitism and self-puffery >>in the "kernels are hard to configure and they *should* be hard to >>configure* attitude. Let's give Aunt Tillie a chance to surprise us. >> > >Whether this is desirable or not is debatable. The big question is: why on >earth would Aunt Tillie _want_ to compile a kernel at all, let alone >re-configure one? If she's using Linux, she's installing her distribution's >pre-compiled kernel, and has no need for anything else. > >Simplifying the configuration interface so that "anyone" can use it seems like >a waste of effort. If there's an interested novice out there who wants to >learn how to configure a kernel, they'll be sufficiently interested to invest >an hour or two in learning how the whole process works. Make it as simple as >it needs to be, and no simpler. > >Charles > Because, for example, a kernel compile can be a part of the standard install now, and you will end up with a kernel built specifically for your machine that doesn't print 50 initialization failed messages on boot. Libranet (Debian offshoot) does that already. It is the only distro that I know of that does this. This also makes it about a thousand times easier for distributions. They don't have to write huge (have you ever looked at Redhat scripts??) init scripts to cover every single possibility and load any module you might need. It's built into the kernel, the way it should be! And you can also now run a kernel built for your shiny new Athlon, not the old piece of shit that was hot stuff in '92. -b -- "One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anything. That to me is far more dangerous than a little pornography on the Internet." - Carl Sagan 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, 19 May 2001 01:57:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 19 May 2001 01:57:16 -0400 Received: from james.kalifornia.com ([208.179.59.2]:2653 "EHLO james.kalifornia.com") by vger.kernel.org with ESMTP id ; Sat, 19 May 2001 01:57:04 -0400 Message-ID: <3B060A79.7090901@kalifornia.com> Date: Fri, 18 May 2001 22:54:01 -0700 From: Ben Ford User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 To: arjanv@redhat.com CC: "Eric S. Raymond" , linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010518115839.E14309@thyrsus.com> <20010518123413.I14309@thyrsus.com> <3B0551B4.CB251F64@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Arjan van de Ven wrote: >"Eric S. Raymond" wrote: > >> >>an old interface in amber do anything to explore new UI possibilities? >> > >kernel != GUI > UI != GUI -- "One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anything. That to me is far more dangerous than a little pornography on the Internet." - Carl Sagan 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, 19 May 2001 02:41:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 19 May 2001 02:40:54 -0400 Received: from nat-pool-meridian.redhat.com ([199.183.24.200]:19136 "EHLO devserv.devel.redhat.com") by vger.kernel.org with ESMTP id ; Sat, 19 May 2001 02:40:41 -0400 Date: Sat, 19 May 2001 02:40:41 -0400 From: Pete Zaitcev Message-Id: <200105190640.f4J6efG11140@devserv.devel.redhat.com> To: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up In-Reply-To: In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518093414.A21164@qcc.sk.ca> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >[about Aunt Tullie] > Because, for example, a kernel compile can be a part of the standard > install now, and you will end up with a kernel built specifically for > your machine that doesn't print 50 initialization failed messages on boot. >[...] > And you can also now run a kernel built for your shiny new Athlon, not > the old piece of shit that was hot stuff in '92. It is way too easy to crush your example, by pointing out that Red Hat ships and automatically installs an Athlon-optimized kernel. However, the argument above is wrong even if Red Hat did not. We are talking about CML2 and interaction with Aunt Tullie. This has nothing to do with automated rebuild at install time. -- Pete 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, 19 May 2001 06:14:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 19 May 2001 06:14:24 -0400 Received: from james.kalifornia.com ([208.179.59.2]:56158 "EHLO james.kalifornia.com") by vger.kernel.org with ESMTP id ; Sat, 19 May 2001 06:14:08 -0400 Message-ID: <3B064690.2040803@kalifornia.com> Date: Sat, 19 May 2001 03:10:24 -0700 From: Ben Ford User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518093414.A21164@qcc.sk.ca> <200105190640.f4J6efG11140@devserv.devel.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Pete Zaitcev wrote: >>[about Aunt Tullie] >>Because, for example, a kernel compile can be a part of the standard >>install now, and you will end up with a kernel built specifically for >>your machine that doesn't print 50 initialization failed messages on boot. >>[...] >>And you can also now run a kernel built for your shiny new Athlon, not >>the old piece of shit that was hot stuff in '92. >> > >It is way too easy to crush your example, by pointing out that >Red Hat ships and automatically installs an Athlon-optimized kernel. > >However, the argument above is wrong even if Red Hat did not. >We are talking about CML2 and interaction with Aunt Tullie. >This has nothing to do with automated rebuild at install time. > >-- Pete > First off, the lady's name was Tillie ;) Second, how many kernels does Redhat ship in order to have one for 386/486/586/k6/Athlon . . . . Quite a pain in the ass. And look at how much shit has to be built in in order to get a kernel that works for everybody! People bitch at Microsoft for doing it, then turn around and do the same thing. And nobody said anything about an automated rebuild. I said a custom kernel build at install time. I said nothing about having it automated. I wouldn't trust an automated build anyways, especially if it came from Redhat. With the philosophy ESR is aiming at, it would be all to easy to ask the user if they'd like to build a custom kernel, then present them with Eric's interface. And that has everything to do with interaction with good ole Aunt Tillie. -b -- "One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anything. That to me is far more dangerous than a little pornography on the Internet." - Carl Sagan 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, 19 May 2001 06:58:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 19 May 2001 06:57:52 -0400 Received: from fenrus.demon.co.uk ([158.152.228.152]:58268 "EHLO amadeus.home.nl") by vger.kernel.org with ESMTP id ; Sat, 19 May 2001 06:57:35 -0400 Message-Id: Date: Sat, 19 May 2001 11:55:34 +0100 (BST) From: arjan@fenrus.demon.nl (Arjan van de Ven) To: ben@kalifornia.com (Ben Ford) Subject: Re: CML2 design philosophy heads-up X-Newsgroups: fenrus.linux.kernel In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518093414.A21164@qcc.sk.ca> <200105190640.f4J6efG11140@devserv.devel.redhat.com> <3B064690.2040803@kalifornia.com> User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (Linux/2.2.19 (i586)) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In article <3B064690.2040803@kalifornia.com> you wrote: > Second, how many kernels does Redhat ship in order to have one for > 386/486/586/k6/Athlon . . . . We build a lot of them :) > Quite a pain in the ass. And look at how much shit has to be built in > in order to get a kernel that works for everybody! People bitch at > Microsoft for doing it, then turn around and do the same thing. MODULES > I said a custom kernel build at install time. I said nothing about > having it automated. I wouldn't trust an automated build anyways, > especially if it came from Redhat. With the philosophy ESR is aiming > at, it would be all to easy to ask the user if they'd like to build a > custom kernel, then present them with Eric's interface. And that has > everything to do with interaction with good ole Aunt Tillie. There is one important point here: NOBODY objects to having a simple interface. KDE people made one, ESR is cloning their idea, fine with me. I and several others object to TAKING AWAY the "advanced" tool that _does_ allow me to build a kernel for "my freak hardware". ESR's method is incompatible with that. He wants to not even ask the questions that he considers weird for a particular machine. So if I connect a cdromdrive to my iPAQ, I'll have to resort to vi/emacs. That's not progress. There is a distinction between "true dependencies" on a sourcecode level (eg the PDC202xx IDE driver requires the core IDE code to be built in) and dependencies/requirements/auto-selects on an "Aunt Tillie" level (eg I have a Dell Machine type FOO -> IDE + proper controller are selected and VooDoo7 3D cards are asked / looked up in PCI config space). The current Config.in system is not much more than making the true dependencies explicit. AND that is enough for some of the GUI kernel config tools out there to make an Aunt Tillie level config program. Yes they need to add extra information. Some of that can even be extracted from the PCI tables in the driver-sourcecode. Taking away the true dependency information and replacing it by things that are likely/unlikely is bad. It will work for 95% of the PC's out there, sure. There's freak hardware. People build freak kernels. Heck, when I build the Red Hat Linux kernel, ESR would call that a freak kernel. Because it supports hardware combinations that are VERY unlikely. The kernel both supports ISA NIC's and 8way SMP servers. Yes you're a freak if you put a ISA NIC in your 8way server. But YES the Red Hat kernel needs both, although it's unlikely you need both on the same machine. Greetings, Arjan van de Ven 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, 19 May 2001 12:20:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 19 May 2001 12:19:54 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:6916 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Sat, 19 May 2001 12:19:42 -0400 Subject: Re: CML2 design philosophy heads-up To: ben@kalifornia.com (Ben Ford) Date: Sat, 19 May 2001 17:13:36 +0100 (BST) Cc: linux-kernel@vger.kernel.org In-Reply-To: <3B064690.2040803@kalifornia.com> from "Ben Ford" at May 19, 2001 03:10:24 AM X-Mailer: ELM [version 2.5 PL3] 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 > Second, how many kernels does Redhat ship in order to have one for > 386/486/586/k6/Athlon . . . . > Quite a pain in the ass. And look at how much shit has to be built in > in order to get a kernel that works for everybody! People bitch at > Microsoft for doing it, then turn around and do the same thing. No people bitch at microsoft for precisely the opposite - not including a way to build fully optimised setups for each cpu type - not including all the stuff that is needed (try a generic win2k install on a vaio one day) I think you have your facts backwards Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 19 May 2001 17:58:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 19 May 2001 17:58:00 -0400 Received: from james.kalifornia.com ([208.179.59.2]:867 "EHLO james.kalifornia.com") by vger.kernel.org with ESMTP id ; Sat, 19 May 2001 17:57:52 -0400 Message-ID: <3B06EBAF.20407@kalifornia.com> Date: Sat, 19 May 2001 14:54:55 -0700 From: Ben Ford User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox wrote: >>Second, how many kernels does Redhat ship in order to have one for >>386/486/586/k6/Athlon . . . . >>Quite a pain in the ass. And look at how much shit has to be built in >>in order to get a kernel that works for everybody! People bitch at >>Microsoft for doing it, then turn around and do the same thing. >> > >No people bitch at microsoft for precisely the opposite - not including a >way to build fully optimised setups for each cpu type - not including all the >stuff that is needed (try a generic win2k install on a vaio one day) > >I think you have your facts backwards > >Alan > No, my point was, if I don't have SCSI or RAID on this box, I don't want them to be built into the kernel! In other words, "stuff I don't need, just like Microsoft". -b -- "One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anything. That to me is far more dangerous than a little pornography on the Internet." - Carl Sagan 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, 19 May 2001 20:14:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 19 May 2001 20:14:43 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:59910 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Sat, 19 May 2001 20:14:41 -0400 Subject: Re: CML2 design philosophy heads-up To: ben@kalifornia.com (Ben Ford) Date: Sun, 20 May 2001 01:08:42 +0100 (BST) Cc: linux-kernel@vger.kernel.org In-Reply-To: <3B06EBAF.20407@kalifornia.com> from "Ben Ford" at May 19, 2001 02:54:55 PM X-Mailer: ELM [version 2.5 PL3] 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 > No, my point was, if I don't have SCSI or RAID on this box, I don't want > them to be built into the kernel! They arent built into the kernel. I still think you have your facts confused 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, 20 May 2001 07:20:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 07:20:09 -0400 Received: from t2.redhat.com ([199.183.24.243]:28915 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 07:20:03 -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: <20010518114922.C14309@thyrsus.com> In-Reply-To: <20010518114922.C14309@thyrsus.com> <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> To: esr@thyrsus.com Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 May 2001 12:19:59 +0100 Message-ID: <8485.990357599@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org esr@thyrsus.com said: > I'll take that as a vote for (b), to handle even perverse > configurations even if it means adding a lot of complexity to the > ruleset. As long as the ruleset is sufficient to represent the desired parts of the original behaviour of CML1, that should be fine. Which means that it must be possible to individually select drivers which aren't standard for your board. The dependencies in CML1 are (supposed to be) absolute - the 'advisory' dependencies you're adding are arguably a useful feature, but please don't make it possible to confuse the two, and please do make sure it's possible to disable the latter form. I'm one of the people who Jes has heard saying both 'I don't care' and 'NO!'. The latter on the occasions when it seems you're going to be reducing the usablility of the existing system. I am happiest when my interaction with the config system consists only of 'cvs {commit,update} .config' 'pico .config' and 'make oldconfig'. I don't configure kernels for new boards very often - but on the occasions I do, it's often embedded boards based on a reference design, with irrelevant hardware omitted and some new stuff added in. Having the capability to fix up CVS conflicts in 'make oldconfig' would be a random feature creep that I _would_ approve of :) -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 May 2001 11:20:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 11:20:32 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:32782 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 11:20:18 -0400 Date: Sun, 20 May 2001 11:18:56 -0400 From: "Eric S. Raymond" To: David Woodhouse Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Message-ID: <20010520111856.C3431@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010518114922.C14309@thyrsus.com> <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8485.990357599@redhat.com>; from dwmw2@infradead.org on Sun, May 20, 2001 at 12:19:59PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org David Woodhouse : > The dependencies in CML1 are (supposed to > be) absolute - the 'advisory' dependencies you're adding are arguably a > useful feature, but please don't make it possible to confuse the two, and > please do make sure it's possible to disable the latter form. I don't understand this request. I have no concept of `advisory' dependencies. What are you talking about? Is my documentation horribly unclear? -- Eric S. Raymond "Both oligarch and tyrant mistrust the people, and therefore deprive them of arms." --Aristotle 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, 20 May 2001 11:34:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 11:34:42 -0400 Received: from t2.redhat.com ([199.183.24.243]:60403 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 11:34:30 -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: <20010520111856.C3431@thyrsus.com> In-Reply-To: <20010520111856.C3431@thyrsus.com> <20010518114922.C14309@thyrsus.com> <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> To: esr@thyrsus.com Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 May 2001 16:34:26 +0100 Message-ID: <15823.990372866@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org esr@thyrsus.com said: > I don't understand this request. I have no concept of `advisory' > dependencies. What are you talking about? Is my documentation > horribly unclear? By 'dependency' I refer to the case where the value of one symbol is derived entirely from, or the range of possible values is limited by, the value of another symbol. There are differing reasons for this, which should be treated entirely separately. On one hand you have dependencies which are present to make life easier for Aunt Tillie, by refraining from confusing her with strange questions to which the answer is _probably_ 'no'. Like the question of whether she has an IDE controller on her MVME board. One the other hand, you have the dependencies present in the existing CML1 configuration, which are _absolute_ dependencies - which specify for example that you cannot enable support for PCI peripherals if !CONFIG_PCI, etc. These dependencies are there to prevent you from enabling combinations of options which are utterly meaningless, and usually won't even compile. The former type of dependency should^HMUST be optional. Those who know what they're doing will want to turn them off. I see a lot of boards based on some reference design or other but with a few tweaks and added or removed devices - that's what the reference designs are there for; after all. By making a distinction between the two types of dependency in the configuration language, you can pander to Aunt Tillie without actually getting on the tits of those who don't wish to be arbitrarily restricted from enabling support for the device they _know_ is present because they just soldered it to the blinkin' circuit board. :) -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 May 2001 11:34:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 11:34:32 -0400 Received: from ppp0.ocs.com.au ([203.34.97.3]:19979 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Sun, 20 May 2001 11:34:16 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: esr@thyrsus.com cc: David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up In-Reply-To: Your message of "Sun, 20 May 2001 11:18:56 -0400." <20010520111856.C3431@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 May 2001 01:34:09 +1000 Message-ID: <5800.990372849@ocs3.ocs-net> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 20 May 2001 11:18:56 -0400, "Eric S. Raymond" wrote: >David Woodhouse : >> The dependencies in CML1 are (supposed to >> be) absolute - the 'advisory' dependencies you're adding are arguably a >> useful feature, but please don't make it possible to confuse the two, and >> please do make sure it's possible to disable the latter form. > >I don't understand this request. I have no concept of `advisory' dependencies. >What are you talking about? Is my documentation horribly unclear? People read documentation? No chance. Some people have got it into their heads that the "Aunt Tillie" method of configuration will be the only one allowed. They do not realise that this is the novice method, experts can still do what they like. For dwm's "advisory dependencies", read novice mode, and of course it can be overridden by people who know what they are doing. 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, 20 May 2001 11:45:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 11:45:43 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:47118 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 11:45:34 -0400 Date: Sun, 20 May 2001 11:44:11 -0400 From: "Eric S. Raymond" To: David Woodhouse Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Message-ID: <20010520114411.A3600@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15823.990372866@redhat.com>; from dwmw2@infradead.org on Sun, May 20, 2001 at 04:34:26PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org David Woodhouse : > On one hand you have dependencies which are present to make life easier for > Aunt Tillie, by refraining from confusing her with strange questions to > which the answer is _probably_ 'no'. Like the question of whether she has > an IDE controller on her MVME board. > > One the other hand, you have the dependencies present in the existing CML1 > configuration, which are _absolute_ dependencies - which specify for example > that you cannot enable support for PCI peripherals if !CONFIG_PCI, etc. > These dependencies are there to prevent you from enabling combinations of > options which are utterly meaningless, and usually won't even compile. There are no `advisory' dependencies in CML2. They're all absolute. What you call an `advisory' dependency would be simulated by having a policy symbol for Aunt Tillie mode and writing constraints like this: require AUNT_TILLIE implies FOO >= BAR This is exactly why the CML2 ruleset has EXPERT, WIZARD, and TUNING policy symbols, as hooks for doing things like this. -- Eric S. Raymond No one who's seen it in action can say the phrase "government help" without either laughing or crying. 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, 20 May 2001 11:56:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 11:56:23 -0400 Received: from t2.redhat.com ([199.183.24.243]:4596 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 11:56:13 -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: <20010520114411.A3600@thyrsus.com> In-Reply-To: <20010520114411.A3600@thyrsus.com> <20010518034307.A10784@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> To: esr@thyrsus.com Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 May 2001 16:56:10 +0100 Message-ID: <16267.990374170@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org esr@thyrsus.com said: > There are no `advisory' dependencies in CML2. They're all absolute. > What you call an `advisory' dependency would be simulated by having a > policy symbol for Aunt Tillie mode and writing constraints like this: > require AUNT_TILLIE implies FOO >= BAR > This is exactly why the CML2 ruleset has EXPERT, WIZARD, and TUNING > policy symbols, as hooks for doing things like this. Excellent. Then I apologise for not reading the documentation. After the discussion of MAC and SCSI config options many moons ago in this thread, I was left with the impression that the constraints which were being objected to were not dependent upon a NOVICE mode, but were unconditional. Was this merely a mistake in the conversion of the ruleset? Do you have a policy that the default behaviour should be similar to that of CML1, or at least that such behaviour should be available through one of the modes? If not, please consider doing so. -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 May 2001 13:16:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 13:16:33 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:55822 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 13:16:23 -0400 Date: Sun, 20 May 2001 13:14:57 -0400 From: "Eric S. Raymond" To: David Woodhouse Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Background to the argument about CML2 design philosophy Message-ID: <20010520131457.A3769@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <16267.990374170@redhat.com>; from dwmw2@infradead.org on Sun, May 20, 2001 at 04:56:10PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Those of you who have become confused about the current argument over CML2 should read this... David Woodhouse : > After the discussion of MAC and SCSI config options many moons ago in this > thread, I was left with the impression that the constraints which were > being objected to were not dependent upon a NOVICE mode, but were > unconditional. > > Was this merely a mistake in the conversion of the ruleset? Do you have a > policy that the default behaviour should be similar to that of CML1, or at > least that such behaviour should be available through one of the > modes? If not, please consider doing so. They were unconditional. It looks like a recap of history is in order. Until very recently, like ten days ago, I had a policy of altering the CML1 behavior as little as possible while I got CML2 up and running. Some change had been inevitable because of the move to a single-apex menu tree, but I tried to hold that to a minimum. But I have reached a point where the configurator codebase is stable and works as a drop-in install on top of a stock kernel tree. I'm not even getting requests for UI tweaks any more. So the CML2 engine is essentially done (modulo the occasional minor bugfix). This made it time to start thinking about tuning the rulesfile to make configuration easier. At the same time, I was dealing with another problem; missing entries in Configure.help. When I got handed the maintainer's baton, there were 547 of these. I have written outright over 300 new ones; Steven Cole and I have collected another 50 or so. To reduce the problem further, I looked for symbols with missing entries that I could turn into derivations, eliminating their questions and the requirement for a help entry. (A CML2 derivation is like a CML1 define; it's a formula that sets a symbol from the value of other symbols without user input.) The first candidates I found were questions associated with built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and Sun3x, and with built-in facilities on the MVME147 single-board computer. So I wrote derivations that looked like this: # These were separate questions in CML1. They enable on-board peripheral # controllers in single-board computers. derive MVME147_NET from MVME147 & NET_ETHERNET derive MVME147_SCC from MVME147 & SERIAL derive MVME147_SCSI from MVME147 & SCSI derive MVME16x_NET from MVME16x & NET_ETHERNET derive MVME16x_SCC from MVME16x & SERIAL derive MVME16x_SCSI from MVME16x & SCSI derive BVME6000_NET from BVME6000 & NET_ETHERNET derive BVME6000_SCC from BVME6000 & SERIAL derive BVME6000_SCSI from BVME6000 & SCSI # These were separate questions in CML1 derive MAC_SCC from MAC & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI By doing this I killed two birds with one stone -- got rid of some holes in Configure.help and (more importantly) moved the configuration experience away from low-level, hardware-oriented questions towards where I think it ought to be. That is, you specify a platform and the services you want and the ruleset computes the low-level facilities to be linked in. This represented a change in the design philosophy of the ruleset, not something I wanted to do without input from the developers and port managers. So I broadcast "CML2 design philosophy heads up". After some back-and-forthing about the technical facts, several things emerged: 1. The Mac derivations were half-right. The MAC_SCC one is good but Macs can have either of two different SCSI controllers. I fixed that with help from Ray Knight, who maintains the 68K Mac port. 2. Nobody had a problem with the SUN3_SCSI derivation. 3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. (I missed these possibilities when I wrote the derivations.) I used case 3 to explore a touchy question about design philosophy, which is really what caused all hell to break loose. The question is this: holding down configuration complexity is a good thing, but supporting all hardware configurations that are conceivably possible is also a good thing. How should we trade these good things off against one another? The MVME situation is an almost perfect test case, because while breaking the assumption behind that derivation is physically possible it would be a rather perverse thing to do. The VME147 is an old design, dating from 1988; it's long since been superseded by MPCxxx SBCs based on the PowerPC that have a better processor, lower power consumption, and more on-board peripheral hardware. IDE/ATAPI didn't exist during most of its design lifetime, and the only way anyone is ever going to hook an outboard device to one of these puppies again is if some hacker pulls a dusty one off a shelf for some garage project. So the real question here is whether it is ever acceptable to say that a possible configuration is just silly and ruleset will ignore it, in order to hold down ruleset complexity and simplify the user experience. The cost of deciding that the answer to that question is "yes, sometimes" is that on rare occasions like this one you might have to haul out a text editor to tweak something in your config. But the cost of deciding that the answer is "no" will be some pretty serious complexity headaches both in the configuration user experience and (down the road) in the maintainability of the ruleset. So far, I have to say I'm disappointed in the quality of the debate. Almoist nobody seems to want to think about this tradeoff globally, as a systems design issue. Instead, I'm hearing a lot of reflexive chuntering that we have to do things a certain way because we've always done them a certain way, and who am I to even dare *think* about raising different possibilities? -- Eric S. Raymond [The disarming of citizens] has a double effect, it palsies the hand and brutalizes the mind: a habitual disuse of physical forces totally destroys the moral [force]; and men lose at once the power of protecting themselves, and of discerning the cause of their oppression. -- Joel Barlow, "Advice to the Privileged Orders", 1792-93 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, 20 May 2001 13:47:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 13:47:45 -0400 Received: from t2.redhat.com ([199.183.24.243]:24052 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 13:47:36 -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: <20010520131457.A3769@thyrsus.com> In-Reply-To: <20010520131457.A3769@thyrsus.com> <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> To: esr@thyrsus.com Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 May 2001 18:47:31 +0100 Message-ID: <18686.990380851@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Thankyou for the clarification. esr@thyrsus.com said: > I used case 3 to explore a touchy question about design philosophy, > which is really what caused all hell to break loose. The question is > this: holding down configuration complexity is a good thing, but > supporting all hardware configurations that are conceivably possible > is also a good thing. How should we trade these good things off > against one another? I think you already have the mechanism required to answer this - in NOVICE mode you disallow the strange choices, in EXPERT mode you allow them. Embedded boards are a special case in this respect - people add all manner of strange crap to the reference designs - believe me, I've seen the ways in which they can fuck it up and yet still they manage to amaze me sometimes. And because of the multitude of ways in which the monkeys who glue together these boards can fuck it up, often you really really want to ignore the on-board Ethernet, for example, and use the PCMCIA card you plugged in, because they actually managed to route the PCMCIA interrupt to an IRQ line, not a GPIO pin. esr@thyrsus.com said: > So the real question here is whether it is ever acceptable to say that > a possible configuration is just silly and ruleset will ignore it, in > order to hold down ruleset complexity and simplify the user > experience. The cost of deciding that the answer to that question is > "yes, sometimes" is that on rare occasions like this one you might > have to haul out a text editor to tweak something in your config. As I said earlier, there are two main cases which should be considered entirely separately. There are the cases which are insane, and which won't ever work, or probably even compile. Those should be hard-coded off in the ruleset and it should not be possible to enable them without hacking. For the cases where we just want to make life simpler for the users, the constraints should be dependent on the user mode. In NOVICE mode you hide them, in EXPERT mode you make them available. The current (CML1) solution has problems, and it only provides real support for a small range of people at the hacker end of the spectrum. Making CML2 useful for a far wider range of people is a laudable goal. But please take care to ensure that the set of people for whom CML2 is useful is a strict superset of those for whom CML1 was useful. In particular, please don't strive to make Aunt Tillie happy on the one occasion on which she configures her kernel at a cost of rendering CML2 less useful for those for whom kernel configuration is an every-day task. Once weighted appropriately, that tradeoff is particularly easy to decide upon. If you ever find yourself seriously suggesting that a developer would need to ditch CML2 and hack the config files directly in order to compile support for, for example, the DiskOnChip he just dropped into the DIL socket in his Ethernet card, then I would suggest that you have made a wrong choice somewhere down the road. Please backtrack and reconsider an earlier decision before you're eaten by a grue. We already have a distinction between config options which it's sensible to ask the user, and options for which you have to hack #defines in the source code. The options which I have put into drivers/mtd/Config.in are there because I _wanted_ the user to see them. The options which are hidden in the code are there because I made the opposite decision. There is a reasonably well-defined boundary for such things already, and it's found all over the kernel. Adding a new, higher boundary for Aunt Tillie is just fine - but please don't _move_ the existing one that most of us care about. -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 May 2001 14:32:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 14:32:10 -0400 Received: from turnover.lancs.ac.uk ([148.88.17.220]:51440 "EHLO helium.chromatix.org.uk") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 14:32:00 -0400 Message-Id: In-Reply-To: <20010520131457.A3769@thyrsus.com> In-Reply-To: <16267.990374170@redhat.com>; from dwmw2@infradead.org on Sun, May 20, 2001 at 04:56:10PM +0100 <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 May 2001 19:31:12 +0100 To: esr@thyrsus.com, David Woodhouse From: Jonathan Morton Subject: Re: Background to the argument about CML2 design philosophy Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >1. The Mac derivations were half-right. The MAC_SCC one is good but Macs >can have either of two different SCSI controllers. I fixed that with help >from Ray Knight, who maintains the 68K Mac port. If I understand the "philosophy" correctly, it is still possible to specify additional cards for those Macs which have PCI slots. If so, absolutely fine - I can shove my Adaptec 19160 into my G4 and have it work just as well as it currently does in my Athlon. One caveat though - not all Macs have SCSI controllers, and not all that do even have one of the two standard ones. The "Blue and White G3", the iMac, the PowerBook G3 "Firewire" and later models on these lines all lack a built-in SCSI controller, but many could have one added via PCI or CardBus slots. The PowerBooks 5300 and 190 (and possibly others) use some non-standard P.O.S. hanging off the NuBus, which even mkLinux doesn't know how to drive. However, in these situations, disabling the extra drivers is usually not critical unless you're running low on space somewhere. At that point, you enable the "Are you insane?" module outlined below... >3. The MVME derivations are correct *if* (and only if) you agree to ignore >the possibility that somebody could want to ignore the onboard hardware, >plug outboard disk or Ethernet cards into the VME-bus connector, and >do something like running SCSI-over-ATAPI to the outboard device. >(I missed these possibilities when I wrote the derivations.) ...and then someone else mentioned the possibility of f*x0r3d hardware. In this case, I would say this *isn't* a kernel-configuration issue but one of being able to disable the drivers for the malfunctioning hardware. If I have a PCMCIA controller that reboots the machine as soon as the driver tries to switch it on, I should be able to send a command-line parameter to the kernel which tells it to switch it off *at run-time*. And iff I'm running with hardware which is so f*x0r3d that that isn't enough, I'd either fix the hardware or hack the config files. I don't see the problem. I think the MVME derivations are *perfectly* sensible - if the reference board and most (read: virtually all) derivatives have those features, turn them on by all means. To satisfy some others, you might want to say "Hey, these guys might want to *explicitly turn off* some of this stuff" - so provide an option under "Are you insane?" which presents all the "derived" symbols and allows the hackers to manually turn stuff off. -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi@cyberspace.org (not for attachments) big-mail: chromatix@penguinpowered.com uni-mail: j.d.morton@lancaster.ac.uk The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -----BEGIN GEEK CODE BLOCK----- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -----END GEEK CODE BLOCK----- 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, 20 May 2001 16:16:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 16:16:00 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:6671 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 16:15:49 -0400 Date: Sun, 20 May 2001 16:13:21 -0400 From: "Eric S. Raymond" To: Jonathan Morton Cc: David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Message-ID: <20010520161321.D4488@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Jonathan Morton , David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from chromi@cyberspace.org on Sun, May 20, 2001 at 07:31:12PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jonathan Morton : > One caveat though - not all Macs have SCSI controllers, and not all that do > even have one of the two standard ones. I know. But these derivations are only for the old 68K macs, which don't have PCI. Closed issue. > >3. The MVME derivations are correct *if* (and only if) you agree to ignore > >the possibility that somebody could want to ignore the onboard hardware, > >plug outboard disk or Ethernet cards into the VME-bus connector, and > >do something like running SCSI-over-ATAPI to the outboard device. > > ...and then someone else mentioned the possibility of f*x0r3d hardware. In > this case, I would say this *isn't* a kernel-configuration issue but one of > being able to disable the drivers for the malfunctioning hardware. But the other side is going to ask: suppose you're memory-limited (quite likely on older SBCs) and don't want to pay the core cost of drivers you won't use? I don't really think we can duck this question by talking about boot-time parameters. > I think the MVME derivations are *perfectly* sensible - if the reference > board and most (read: virtually all) derivatives have those features, turn > them on by all means. That's my gut feeling, too. But a lot of people insist that the only right way is totally fine-grained control, even in weird edge cases like this one. > To satisfy some others, you might want to say "Hey, > these guys might want to *explicitly turn off* some of this stuff" - so > provide an option under "Are you insane?" which presents all the "derived" > symbols and allows the hackers to manually turn stuff off. Interesting thought... -- Eric S. Raymond I cannot undertake to lay my finger on that article of the Constitution which grant[s] a right to Congress of expending, on objects of benevolence, the money of their constituents. -- James Madison, 1794 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, 20 May 2001 16:48:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 16:48:42 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:12559 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 16:48:24 -0400 Date: Sun, 20 May 2001 16:47:00 -0400 From: "Eric S. Raymond" To: David Woodhouse Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Message-ID: <20010520164700.H4488@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <18686.990380851@redhat.com>; from dwmw2@infradead.org on Sun, May 20, 2001 at 06:47:31PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org David Woodhouse : > I think you already have the mechanism required to answer this - in NOVICE > mode you disallow the strange choices, in EXPERT mode you allow them. That pushes the third button. I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Sigh... -- 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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 May 2001 17:00:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 16:59:54 -0400 Received: from t2.redhat.com ([199.183.24.243]:50676 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 16:59:43 -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: <20010520164700.H4488@thyrsus.com> In-Reply-To: <20010520164700.H4488@thyrsus.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> To: esr@thyrsus.com Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 May 2001 21:59:39 +0100 Message-ID: <22842.990392379@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org esr@thyrsus.com said: > I'm nervous that if we go down this path we will end up with a > thicket of modes and a combinatorial explosion in ruleset complexity, > leading immediately to a user configuration experience that is more > complex than necessary, and eventually to an unmaintainable mess in > the rulesfiles. Having too many such modes would be a horrible mess, I agree. > In order to prevent that happening, I would like to have some > recognized criterion for configuration cases that are so perverse that > it is a net loss to accept the additional complexity of handling them > within the configurator. > A lot of people (including, apparently, you) are saying there are no > such cases. I wonder if you'll change your minds when you have to > handle the overhead yourselves? Of course there are such cases. The criterion is that the code does not compile or if it did, it could never be expected to work - like SCSI drivers without SCSI generic, or PCI devices without CONFIG_PCI. This is the major criterion which has defined the dependencies already in the config files. You want to add a new mode which hides some of the more esoteric options. That's fine. So do so, and then we have two modes. It's still not an unmaintainable mess. If having even two modes is going to be too troublesome, then keep the one we have. You can try to simplify it later by encouraging individual maintainers to hide stuff behind CONFIG_*_ADVANCED options. But keep that strictly separate from the CML2 discussion. -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 May 2001 17:00:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 17:00:13 -0400 Received: from nat-pool-meridian.redhat.com ([199.183.24.200]:36106 "EHLO devserv.devel.redhat.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 16:59:56 -0400 Date: Sun, 20 May 2001 16:59:52 -0400 From: Arjan van de Ven To: "Eric S. Raymond" , David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Message-ID: <20010520165952.A9622@devserv.devel.redhat.com> In-Reply-To: <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@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: <20010520164700.H4488@thyrsus.com>; from esr@thyrsus.com on Sun, May 20, 2001 at 04:47:00PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 20, 2001 at 04:47:00PM -0400, Eric S. Raymond wrote: > In order to prevent that happening, I would like to have some recognized > criterion for configuration cases that are so perverse that it is a > net loss to accept the additional complexity of handling them within the > configurator. "It doesn't compile/link" would be a good one. "It requires subsystem FOO to operate" is another (think about IDE DMA drivers and the IDE subsystem, or NIC drivers vs CONFIG_NET) > A lot of people (including, apparently, you) are saying there are no such > cases. I wonder if you'll change your minds when you have to handle the > overhead yourselves? Somehow the current overhead isn't that high. You might argue that the current Config.in is broken given my definition. That is fixable with a day of work; I've been doing so on a regular basis with the tooling I wrote for automatic testing of this. Maybe it would be possible to separate "hard" dependencies like the current system has with the "soft" ones one needs for entry-level configtools. Or maybe it needs 2 files for that.. CML1 style (style, maybe not syntax) ones and the newstyle info. I liked the suggestion where the "automatic" derivations got turned into manual ones for expert mode... I haven't tried CML2 yet (I've yet to find a suitable .deb of Python2 for my Debian Potato playbox) so I don't know if that is actually possible, or that it requires some redesign. Greetings, Arjan van de Ven 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, 20 May 2001 17:10:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 17:09:55 -0400 Received: from blount.mail.mindspring.net ([207.69.200.226]:10514 "EHLO blount.mail.mindspring.net") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 17:09:46 -0400 Subject: Re: Background to the argument about CML2 design philosophy From: Robert "M." Love To: linux-kernel@vger.kernel.org Cc: David Woodhouse In-Reply-To: <20010520164700.H4488@thyrsus.com> In-Reply-To: <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 20 May 2001 17:10:01 -0400 Message-Id: <990393002.1322.4.camel@phantasy> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 20 May 2001 16:47:00 -0400, Eric S. Raymond wrote: > In order to prevent that happening, I would like to have some recognized > criterion for configuration cases that are so perverse that it is a > net loss to accept the additional complexity of handling them within the > configurator. > > A lot of people (including, apparently, you) are saying there are no such > cases. I wonder if you'll change your minds when you have to handle the > overhead yourselves? I feel that there should *never ever* be a legit situation that the configuration tool does not allow. Not ever. Two reasons: First, I tend to trust the config tools (perhaps too much). If they tell me x implies y, or x implies not y, I will believe it. I won't think "hm, the code must be wrong, let me hand edit the config" (which is something I don't want to have to do, anyhow). Second, I like having a lean kernel. Here is an example (I realize this probably won't ever manifest into a real rule): INTEL_I815 implies INTEL_RNG, DRM_I810, INTEL_AGP, I810_TCO, PCI, etc etc. -- I don't want the RNG or TCO watchdog. I don't use the on-board graphics. Nor, if my i815 model supported it, the sound. There are people who want to customize their kernel (hell, everyone at this level of the game). There are people, like David, who have custom setups. We need to support this, without hacking the config (especially if I have to rehack it after every make oldconfig!). I like your design to abstract away low levels features to a more general design. This makes it easier for the novice, and more intuitive for everyone. But not at the expense of limiting possible cases. -- Robert M. Love rml@ufl.edu rml@tech9.net 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, 20 May 2001 18:52:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 18:52:09 -0400 Received: from t2.redhat.com ([199.183.24.243]:9717 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 18:52:00 -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: <20010520165952.A9622@devserv.devel.redhat.com> In-Reply-To: <20010520165952.A9622@devserv.devel.redhat.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> To: Arjan van de Ven Cc: "Eric S. Raymond" , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 May 2001 23:51:56 +0100 Message-ID: <25499.990399116@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org arjanv@redhat.com said: > Maybe it would be possible to separate "hard" dependencies like the > current system has with the "soft" ones one needs for entry-level > configtools. Actually, the current system has both types. As well as the "hard" dependencies, we also have stuff like CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED, CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED, etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too. These things have already been set up in the way that developers prefer it. CML2 allows us to be more flexible than we were before, and that can be a good thing when used in moderation. But please, for the sake of the sanity of all concerned, do things one at a time. Provide for merging into 2.5 a set of rules which reproduce the existing CML1 behaviour in this respect. Eric, if you want to make further changes later to introduce new 'modes' for kernel configuration, that's an entirely separate issue. Please don't confuse the issue by trying to do it at the same time as introducing CML2. CONFIG_AUNT_TILLIE does not require CML2. CML2 does not require CONFIG_AUNT_TILLIE. Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing behaviour of config options to make that the default, until we've settled the discussion about CML2. -- dwmw2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 May 2001 20:29:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 20:29:45 -0400 Received: from smtp1.cern.ch ([137.138.128.38]:21254 "EHLO smtp1.cern.ch") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 20:29:32 -0400 To: John Cowan Cc: esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> <3B054500.2090408@reutershealth.com> From: Jes Sorensen Date: 21 May 2001 02:29:17 +0200 In-Reply-To: John Cowan's message of "Fri, 18 May 2001 11:51:28 -0400" Message-ID: User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 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 >>>>> "John" == John Cowan writes: John> Jes Sorensen wrote: >> Telling them to install an updated gcc for kernel compilation is a >> necessary evil, which can easily be done without disturbing the >> rest of the system. Updating the system's python installation is >> not a reasonable request. John> Au contraire. It is very reasonable to have both python and John> python2 installed. Having two different gcc versions installed John> is a big pain in the arse. It's not unreasonable to have both installed, it's unreasonable to require it. Eric seems to think he can tell every distributor to ship Python2 tomorrow. Well it's a fine dream but it's not going to happen; Most distributors do not ship new major versions of tools in their minor number release versions. I've seen him mention the number 6 months until everybody ships it, but a) thats not going to happen Red Hat is currently at 7.1 (if one looks at their release history, one would say there is a good chance there will be a 7.2) not to mention the release rate of Debian (not sure about the current state of all other distributions). 18 months is more realistic for it to be deployed widely enough. >> So far I haven't heard a single developer say something positive >> about CML2, the most positive I have heard so far has been >> "whatever", "it's his choice", "I don't care", "I want to >> hack". The majority are of the "NO!" and "you got to be kiddin'". John> Anonymized hearsay evidence is less than convincing. Well I don't like to quote personal conversations without peoples' approval, now both David Woodhouse and Arjan are two examples. 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 ; Sun, 20 May 2001 20:46:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 20:46:05 -0400 Received: from smtp1.cern.ch ([137.138.128.38]:26632 "EHLO smtp1.cern.ch") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 20:45:53 -0400 To: esr@thyrsus.com Cc: David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy In-Reply-To: <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> From: Jes Sorensen Date: 21 May 2001 02:45:03 +0200 In-Reply-To: "Eric S. Raymond"'s message of "Sun, 20 May 2001 13:14:57 -0400" Message-ID: User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 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 >>>>> "Eric" == Eric S Raymond writes: Eric> The first candidates I found were questions associated with Eric> built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and Eric> Sun3x, and with built-in facilities on the MVME147 single-board Eric> computer. So I wrote derivations that looked like this: [snip derive rules] Eric> # These were separate questions in CML1 derive MAC_SCC from MAC Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from Eric> (SUN3 | SUN3X) & SCSI Eric> By doing this I killed two birds with one stone -- got rid of Eric> some holes in Configure.help and (more importantly) moved the Eric> configuration experience away from low-level, hardware-oriented Eric> questions towards where I think it ought to be. That is, you Eric> specify a platform and the services you want and the ruleset Eric> computes the low-level facilities to be linked in. And you suddenly imposed decisions on people. Wether or not you are an expert it is reasonable to expect that you want to use modules just as it is just as reasonable to expect that you do not. In some cases you want your Ethernet as a module in some case you want the low level SCSI driver but not the SCSI mid layer. Eric> After some back-and-forthing about the technical facts, several Eric> things emerged: Eric> 1. The Mac derivations were half-right. The MAC_SCC one is good Eric> but Macs can have either of two different SCSI controllers. I Eric> fixed that with help from Ray Knight, who maintains the 68K Mac Eric> port. Eric> 2. Nobody had a problem with the SUN3_SCSI derivation. Did you ever get an ACK on it or no answer? Eric> 3. The MVME derivations are correct *if* (and only if) you agree Eric> to ignore the possibility that somebody could want to ignore the Eric> onboard hardware, plug outboard disk or Ethernet cards into the Eric> VME-bus connector, and do something like running SCSI-over-ATAPI Eric> to the outboard device. (I missed these possibilities when I Eric> wrote the derivations.) Or wants to use modules. And yes Aunt Tillie might want to do so, if the person who sold her her Linux CD provided a bunch of scripts for packing up things in a specific way. Eric> The MVME situation is an almost perfect test case, because while Eric> breaking the assumption behind that derivation is physically Eric> possible it would be a rather perverse thing to do. The VME147 Eric> is an old design, dating from 1988; it's long since been Eric> superseded by MPCxxx SBCs based on the PowerPC that have a Eric> better processor, lower power consumption, and more on-board Eric> peripheral hardware. IDE/ATAPI didn't exist during most of its Eric> design lifetime, and the only way anyone is ever going to hook Eric> an outboard device to one of these puppies again is if some Eric> hacker pulls a dusty one off a shelf for some garage project. Bzzzzt wrong. The MVME cards are still heavily used in control systems and similar places. It's the only place where m68k usage is not dying for real. Eric> So far, I have to say I'm disappointed in the quality of the Eric> debate. Almoist nobody seems to want to think about this Eric> tradeoff globally, as a systems design issue. Instead, I'm Eric> hearing a lot of reflexive chuntering that we have to do things Eric> a certain way because we've always done them a certain way, and Eric> who am I to even dare *think* about raising different Eric> possibilities? So far the introduction of CML2 has been overly disppointing, from day one it's been 'I have this great idea and since I think it's great, you obviously have to think so as well'. Now I take it the derived rules are still only enforced under the 'novice' option, though you haven't exactly made that clear in the discussion (nor did you do so when you initially brought it up). 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 ; Sun, 20 May 2001 21:15:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 21:15:31 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:37647 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 21:15:21 -0400 Date: Sun, 20 May 2001 21:13:46 -0400 From: "Eric S. Raymond" To: David Woodhouse Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Message-ID: <20010520211346.A6170@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> <20010520165952.A9622@devserv.devel.redhat.com> <25499.990399116@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <25499.990399116@redhat.com>; from dwmw2@infradead.org on Sun, May 20, 2001 at 11:51:56PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org David Woodhouse : > Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing > behaviour of config options to make that the default, until we've settled > the discussion about CML2. What discussion is that? Unless Linus has changed his mind and I don't know about it, CML2 is going in between 2.5.1 and 2.5.2. The engine is working. Why is it not yet time to discuss ruleset design and modes? -- Eric S. Raymond That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United states who are peaceable citizens from keeping their own arms... -- Samuel Adams, in "Phila. Independent Gazetteer", August 20, 1789 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, 20 May 2001 21:58:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 21:58:46 -0400 Received: from marine.sonic.net ([208.201.224.37]:5492 "HELO marine.sonic.net") by vger.kernel.org with SMTP id ; Sun, 20 May 2001 21:58:29 -0400 X-envelope-info: Date: Sun, 20 May 2001 18:58:27 -0700 From: Mike Castle To: linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010520185827.B16356@thune.mrc-home.com> Reply-To: Mike Castle Mail-Followup-To: Mike Castle , linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: > distributions). 18 months is more realistic for it to be deployed > widely enough. People who are going to be savvy enough to install a development 2.5.* kernel that is defining a new configuration utility are going to be savvy enough to install python. mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen 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, 20 May 2001 22:10:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 22:10:49 -0400 Received: from mclean.mail.mindspring.net ([207.69.200.57]:46124 "EHLO mclean.mail.mindspring.net") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 22:10:41 -0400 Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up From: Robert "M." Love To: Jes Sorensen Cc: John Cowan , esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> <3B054500.2090408@reutershealth.com> Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 20 May 2001 22:10:49 -0400 Message-Id: <990411054.773.0.camel@phantasy> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote: > John> Au contraire. It is very reasonable to have both python and > John> python2 installed. Having two different gcc versions installed > John> is a big pain in the arse. > > It's not unreasonable to have both installed, it's unreasonable to > require it. > > Eric seems to think he can tell every distributor to ship Python2 > tomorrow. Well it's a fine dream but it's not going to happen; I think this is a very important point, and one I agree with. I tend to let my distribution handle stuff like python. now, I use RedHat's on-going devel, RawHide. it is not using python2. in fact, since switching to python2 may break old stuff, I don't expect python2 until 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et al, are written in python1 and they just are not going to change on someone's whim. im not installing python2 from source just so i can run some new config utility. (on another note, about the coexist issue: am i going to have a python and python2 binary? so now the config tool will find which to use, ala the kgcc mess? great) -- Robert M. Love rml@ufl.edu rml@tech9.net 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, 20 May 2001 22:36:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 22:36:05 -0400 Received: from unthought.net ([212.97.129.24]:33712 "HELO mail.unthought.net") by vger.kernel.org with SMTP id ; Sun, 20 May 2001 22:35:59 -0400 Date: Mon, 21 May 2001 04:35:53 +0200 From: =?iso-8859-1?Q?Jakob_=D8stergaard?= To: "Robert M. Love" Cc: Jes Sorensen , John Cowan , esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010521043553.C20911@unthought.net> Mail-Followup-To: =?iso-8859-1?Q?Jakob_=D8stergaard?= , "Robert M. Love" , Jes Sorensen , John Cowan , esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> <3B054500.2090408@reutershealth.com> <990411054.773.0.camel@phantasy> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <990411054.773.0.camel@phantasy>; from rml@tech9.net on Sun, May 20, 2001 at 10:10:49PM -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: > On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote: > > John> Au contraire. It is very reasonable to have both python and > > John> python2 installed. Having two different gcc versions installed > > John> is a big pain in the arse. > > > > It's not unreasonable to have both installed, it's unreasonable to > > require it. > > > > Eric seems to think he can tell every distributor to ship Python2 > > tomorrow. Well it's a fine dream but it's not going to happen; > > I think this is a very important point, and one I agree with. I tend to > let my distribution handle stuff like python. now, I use RedHat's > on-going devel, RawHide. it is not using python2. in fact, since > switching to python2 may break old stuff, I don't expect python2 until > 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et > al, are written in python1 and they just are not going to change on > someone's whim. 2.6.0 isn't going to happen for at least a year or two. What's the problem ? Want 2.5.X ? Get the tools too. I'm in no position to push people around, but I think the whining about CML2 tool requirements is completely unjustified. If we required that everything worked with GCC 2.7.2 and nmake, where would we be today ? I'm a lot more worried about CML2 itself than about the tools it requires :) > > im not installing python2 from source just so i can run some new config > utility. python2 will be in rawhide when 2.5 development requires it, if I'm not much mistaken. Whether CML2 requires python2 or not, the distributions will change. This is not about Eric pushing something down people's throats. Tools evolve, and new revisions introduce incompatibilities, but distributions still follow the evolution. Nobody ships perl4 today either. -- ................................................................ : jakob@unthought.net : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............: 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, 20 May 2001 23:06:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 23:06:29 -0400 Received: from mail.ntplx.net ([204.213.176.10]:33151 "EHLO mail.ntplx.net") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 23:06:13 -0400 Message-ID: <3B088516.68D57DB1@ntplx.net> Date: Sun, 20 May 2001 23:01:42 -0400 From: Ben Bridgwater X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-Kernel Subject: Re: Background to the argument about CML2 design philosophy 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 > derive MVME147_SCSI from MVME147 & SCSI It seems that the preferred semantics would be: default MVME147_SCSI from MVME147 & SCSI That way the platform defines sane defaults, but no flexibility has been taken away. Presumably many of these defaulted options would also be ones that would be configured not to be changeable in novice mode. The novice gets the vanilla platform defaults without being bothered by detailed options, and can switch to expert mode if they need more control. The experts get all the options presented, but also get to benefit from the smart platform defaults. Ben 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, 20 May 2001 23:34:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 23:34:00 -0400 Received: from modemcable084.137-200-24.mtl.mc.videotron.ca ([24.200.137.84]:34286 "EHLO xanadu.home") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 23:33:45 -0400 Date: Sun, 20 May 2001 23:33:34 -0400 (EDT) From: Nicolas Pitre X-X-Sender: To: "Eric S. Raymond" cc: David Woodhouse , Arjan van de Ven , Subject: Re: Background to the argument about CML2 design philosophy In-Reply-To: <20010520164700.H4488@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 20 May 2001, Eric S. Raymond wrote: > In order to prevent that happening, I would like to have some recognized > criterion for configuration cases that are so perverse that it is a > net loss to accept the additional complexity of handling them within the > configurator. Simple: That extreme perversion represent a kernel that wouldn't compile. You can't have NFS support if you didn't select networking support, etc. Such is the recognized basics. Next, you can ask the question if you would have to modify the ruleset to add a new driver to be able to use a feature. Exemple: will you need to write a new driver for a special IDE interface card and add it in the ruleset before you could use IDE cdrom support on the MVME147 SBC? If you have to edit it anyway then it shouldn't be much pain to remove the unconditionnal removal of IDE support for that target. For all other combinations where a slight possibility might make you doubt then the choice should remain at least in expert mode. People might also want to remove support for subsystems on a specific target even if the device comes soldered on it, just because they won't use it anyway and they want to optimize their kernel size for better memory usage. IMHO your design goal now is mainly about finding a way to describe rule derivation related to the selected expertise mode, and only enforce the strictly impossible combinations for expert mode, just like CML1 is doing while removing obvious derivations for novice users. Now you protest with: > That pushes the third button. I'm nervous that if we go down this path > we will end up with a thicket of modes and a combinatorial explosion > in ruleset complexity, leading immediately to a user configuration > experience that is more complex than necessary, and eventually to an > unmaintainable mess in the rulesfiles. Eric: with this I think you know what everybody here is wishing for, and you just perfectly stated your design constraint in achieving it. You can't avoid the "all semi-possible combination allowed" mode. So let's switch to the implementation discussion instead. 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 ; Sun, 20 May 2001 23:39:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 23:39:09 -0400 Received: from modemcable084.137-200-24.mtl.mc.videotron.ca ([24.200.137.84]:35310 "EHLO xanadu.home") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 23:38:53 -0400 Date: Sun, 20 May 2001 23:38:51 -0400 (EDT) From: Nicolas Pitre X-X-Sender: To: "Robert M. Love" cc: , David Woodhouse Subject: Re: Background to the argument about CML2 design philosophy In-Reply-To: <990393002.1322.4.camel@phantasy> 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 20 May 2001, Robert M. Love wrote: > I feel that there should *never ever* be a legit situation that the > configuration tool does not allow. Not ever. Two reasons: > > First, I tend to trust the config tools (perhaps too much). If they > tell me x implies y, or x implies not y, I will believe it. I won't > think "hm, the code must be wrong, let me hand edit the config" (which > is something I don't want to have to do, anyhow). Then just don't go as far as using it in "Expert (might be unsafe)" mode. If you blindly trust the tool that much the intermediate mode might be what you need. 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 ; Sun, 20 May 2001 23:48:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 May 2001 23:48:19 -0400 Received: from modemcable084.137-200-24.mtl.mc.videotron.ca ([24.200.137.84]:37614 "EHLO xanadu.home") by vger.kernel.org with ESMTP id ; Sun, 20 May 2001 23:48:07 -0400 Date: Sun, 20 May 2001 23:47:59 -0400 (EDT) From: Nicolas Pitre X-X-Sender: To: Jes Sorensen cc: John Cowan , , , Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 21 May 2001, Jes Sorensen wrote: > John> Au contraire. It is very reasonable to have both python and > John> python2 installed. Having two different gcc versions installed > John> is a big pain in the arse. > > It's not unreasonable to have both installed, it's unreasonable to > require it. > > Eric seems to think he can tell every distributor to ship Python2 > tomorrow. Well it's a fine dream but it's not going to happen Distributors aren't going to ship Linux 2.5.x tomorrow either. 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 ; Mon, 21 May 2001 01:03:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 01:03:34 -0400 Received: from www.wen-online.de ([212.223.88.39]:31755 "EHLO wen-online.de") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 01:03:14 -0400 Date: Mon, 21 May 2001 07:01:44 +0200 (CEST) From: Mike Galbraith X-X-Sender: To: =?ISO-8859-1?Q?Jakob_=D8stergaard?= cc: "Robert M. Love" , Jes Sorensen , John Cowan , , , Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010521043553.C20911@unthought.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 21 May 2001, Jakob Østergaard wrote: > On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: > > > > im not installing python2 from source just so i can run some new config > > utility. > > python2 will be in rawhide when 2.5 development requires it, if I'm not much > mistaken. Alan said someone is rewriting in C, so the python2 requirement is already becoming a non-problem. -Mike (don't like requirement, but don't think it's a big hairy deal either) 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, 21 May 2001 02:12:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 02:11:58 -0400 Received: from femail1.rdc1.on.home.com ([24.2.9.88]:8613 "EHLO femail1.rdc1.on.home.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 02:11:47 -0400 Date: Mon, 21 May 2001 02:11:39 -0400 (EDT) From: "Mike A. Harris" X-X-Sender: To: "Robert M. Love" cc: Jes Sorensen , John Cowan , , , Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <990411054.773.0.camel@phantasy> Message-ID: X-Unexpected-Header: The Spanish Inquisition X-Spam-To: uce@ftc.gov Copyright: Copyright 2001 by Mike A. Harris - All rights reserved 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 20 May 2001, Robert M. Love wrote: >I think this is a very important point, and one I agree with. I tend to >let my distribution handle stuff like python. now, I use RedHat's >on-going devel, RawHide. it is not using python2. in fact, since >switching to python2 may break old stuff, I don't expect python2 until >8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et >al, are written in python1 and they just are not going to change on >someone's whim. > >im not installing python2 from source just so i can run some new config >utility. > >(on another note, about the coexist issue: am i going to have a python >and python2 binary? so now the config tool will find which to use, ala >the kgcc mess? great) powertools/7.1/SRPMS/python2-2.0-3.src.rpm For the record, the kgcc "mess" you speak of was used by Conectiva, and I believe also by debian before adoption in Red Hat Linux. It was about as good a solution as one could get for the problem that it solved - the kernel being broken and unable to build with our gcc-2.96. Just to head anyone off at the pass... the kernel is fixed and now builds properly with gcc-2.96. Also, if anyone has any questions about gcc-2.96 please see: http://www.bero.org/gcc296.html ---------------------------------------------------------------------- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. ---------------------------------------------------------------------- Microsoft Windows(tm). A 32 bit extension and graphical shell to a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor which was written by a 2 bit company that can't stand 1 bit of competition. 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, 21 May 2001 02:42:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 02:41:52 -0400 Received: from t2.redhat.com ([199.183.24.243]:35062 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 02:41:41 -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: <20010520211346.A6170@thyrsus.com> In-Reply-To: <20010520211346.A6170@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> <20010520165952.A9622@devserv.devel.redhat.com> <25499.990399116@redhat.com> To: esr@thyrsus.com Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Date: Mon, 21 May 2001 07:41:37 +0100 Message-ID: <6382.990427297@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org esr@thyrsus.com said: > What discussion is that? Unless Linus has changed his mind and I > don't know about it, CML2 is going in between 2.5.1 and 2.5.2. Because it is evidently confusing the issue. Perhaps because it sounds like you were intending to feed Linus large patches for 2.5.[12] which effect _both_ changes. Have patience - let the less contentious part of CML2 go in first, and then we can deal with the other stuff later, once CML2 has been accepted (however grudgingly in some cases) by developers. > The engine is working. Why is it not yet time to discuss ruleset design > and modes? For a man who claims to hack social systems, that's an incredibly naïve question. -- 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, 21 May 2001 02:36:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 02:36:32 -0400 Received: from james.kalifornia.com ([208.179.59.2]:56432 "EHLO james.kalifornia.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 02:36:19 -0400 Message-ID: <3B08B6B0.4010907@kalifornia.com> Date: Sun, 20 May 2001 23:33:20 -0700 From: Ben Ford User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 CC: linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010520185827.B16356@thune.mrc-home.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input)@localhost.localdomain Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Mike Castle wrote: >On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: > >>distributions). 18 months is more realistic for it to be deployed >>widely enough. >> > >People who are going to be savvy enough to install a development 2.5.* >kernel that is defining a new configuration utility are going to be savvy >enough to install python. > >mrc > Not only that, but Alan said that somebody is rewriting it in C. -- "One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anything. That to me is far more dangerous than a little pornography on the Internet." - Carl Sagan 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, 21 May 2001 05:15:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 05:15:11 -0400 Received: from hermine.idb.hist.no ([158.38.50.15]:15635 "HELO hermine.idb.hist.no") by vger.kernel.org with SMTP id ; Mon, 21 May 2001 05:15:04 -0400 Message-ID: <3B08DC75.C466BA66@idb.hist.no> Date: Mon, 21 May 2001 11:14:29 +0200 From: Helge Hafting X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.5-pre2 i686) X-Accept-Language: no, en MIME-Version: 1.0 To: esr@thyrsus.com CC: linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy In-Reply-To: <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Eric S. Raymond" wrote: > > To reduce the problem further, I looked for symbols with missing > entries that I could turn into derivations, eliminating their > questions and the requirement for a help entry. Adding help entries is nice. But please don't go around making "unlikely" choices unconditional in order to avoid writing help text. Leaving the help blank for such questions is better than eliminating the question. [...] > By doing this I killed two birds with one stone -- got rid of some holes > in Configure.help and (more importantly) moved the configuration experience > away from low-level, hardware-oriented questions towards where I think it > ought to be. That is, you specify a platform and the services you want and > the ruleset computes the low-level facilities to be linked in. > > 3. The MVME derivations are correct *if* (and only if) you agree to ignore > the possibility that somebody could want to ignore the onboard hardware, > plug outboard disk or Ethernet cards into the VME-bus connector, and > do something like running SCSI-over-ATAPI to the outboard device. > (I missed these possibilities when I wrote the derivations.) > > I used case 3 to explore a touchy question about design philosophy, which > is really what caused all hell to break loose. The question is this: > holding down configuration complexity is a good thing, but supporting > all hardware configurations that are conceivably possible is also a good > thing. How should we trade these good things off against one another? I'd say support all possible configurations that is supposed to work. You never know what someone might want to make out of spare parts and dusty old things. Particularly, not compiling (or modularizing) the driver for a built-in device is always a valid way of saving memory. I don't compile IDE on my home pc, because all my devices are scsi. And the built-in floppy controller is modularized because it is so rarely used. Why give it permanent unswappable memory? Your trade-off considerations should be wether "odd but possible" choices belong in an EXPERT category or if they should be there for everybody. Don't consider eliminating something that would work. Of course you don't have to worry too much about help texts for the expert stuff - let the experts add that themselves if you don't want to write for fringe cases. > The MVME situation is an almost perfect test case, because while > breaking the assumption behind that derivation is physically possible > it would be a rather perverse thing to do. The VME147 is an old > design, dating from 1988; it's long since been superseded by MPCxxx > SBCs based on the PowerPC that have a better processor, lower power > consumption, and more on-board peripheral hardware. IDE/ATAPI didn't > exist during most of its design lifetime, and the only way anyone is > ever going to hook an outboard device to one of these puppies again > is if some hacker pulls a dusty one off a shelf for some garage project. Hackers get things like this for free when companies get rid of them, then turns them into mp3 players or hobby device controllers. > So the real question here is whether it is ever acceptable to say that > a possible configuration is just silly and ruleset will ignore it, in Maybe it is acceptable to say something is too silly. You have to come up with a better example though. People may definitely want to not have a driver, or make a module instead of compiled-in. And they may want to not use the built-in device because they use something better. Like a fast ethernet connected to that old vme box because the net they connect to is fast even though the box may be too weak to really take advantage of it. Or wide scsi instead of the built-in thing. > order to hold down ruleset complexity and simplify the user > experience. The cost of deciding that the answer to that question is The user experience can be simplified by a NOVICE/EASY/SANE_DEFAULTS option, and perhaps a HACKER option for the really strange but _theoretically_ ok stuff. > "yes, sometimes" is that on rare occasions like this one you might > have to haul out a text editor to tweak something in your config. But > the cost of deciding that the answer is "no" will be some pretty > serious complexity headaches both in the configuration user experience > and (down the road) in the maintainability of the ruleset. If EXPERT options makes it too complex, consider having some rules that are advisory only. The debian packaging system has both absolute dependancies, and "suggestions". Consider: suggest MVME16x_SCC from MVME16x & SERIAL which means that someone who turns on MVME16x_SCC and SERIAL get MVME16x_SCC turned on when they do so. But the choice is visible and it is possible for the user to turn it off at will. Maybe shown in a different color or with some other hint that it is a defaulted but overrideable thing. Configuration gets simple for the vast amount of common cases, but experts can do whatever they want. You could even have a user-interface option for not showing such defaulted options. That wouldn't complicate the rulebase, it would be a UI-thing only. Now you get both the simple rulebase and the nice user interface. And satisfied experts. Helge Hafting 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, 21 May 2001 05:59:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 05:59:43 -0400 Received: from smtp1.cern.ch ([137.138.128.38]:37382 "EHLO smtp1.cern.ch") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 05:59:32 -0400 To: Jakob =?iso-8859-1?q?=D8stergaard?= Cc: "Robert M. Love" , John Cowan , esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010505192731.A2374@thyrsus.com> <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> <3B054500.2090408@reutershealth.com> <990411054.773.0.camel@phantasy> <20010521043553.C20911@unthought.net> From: Jes Sorensen Date: 21 May 2001 11:58:34 +0200 In-Reply-To: Jakob =?iso-8859-1?q?=D8stergaard's?= message of "Mon, 21 May 2001 04:35:53 +0200" Message-ID: User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >>>>> "Jakob" == Jakob Østergaard writes: Jakob> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: >> I think this is a very important point, and one I agree with. I >> tend to let my distribution handle stuff like python. now, I use >> RedHat's on-going devel, RawHide. it is not using python2. in >> fact, since switching to python2 may break old stuff, I don't >> expect python2 until 8.0. that wont be for 9 months. 90% of >> RedHat's configuration tools, et al, are written in python1 and >> they just are not going to change on someone's whim. Jakob> 2.6.0 isn't going to happen for at least a year or two. What's Jakob> the problem ? Jakob> Want 2.5.X ? Get the tools too. Some people grab the latest devel kernels because thats all that works on their hardware. Jakob> I'm in no position to push people around, but I think the Jakob> whining about CML2 tool requirements is completely unjustified. Jakob> If we required that everything worked with GCC 2.7.2 and nmake, Jakob> where would we be today ? I'm a lot more worried about CML2 Jakob> itself than about the tools it requires :) gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are not. Jakob> Whether CML2 requires python2 or not, the distributions will Jakob> change. This is not about Eric pushing something down people's Jakob> throats. Tools evolve, and new revisions introduce Jakob> incompatibilities, but distributions still follow the Jakob> evolution. Nobody ships perl4 today either. The point is that Eric has been trying to push distributions to ship P2. 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 ; Mon, 21 May 2001 06:01:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 06:01:43 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:14596 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 06:01:34 -0400 Date: Mon, 21 May 2001 06:04:40 -0400 From: "Eric S. Raymond" To: David Woodhouse Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Message-ID: <20010521060440.A1738@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> <20010520165952.A9622@devserv.devel.redhat.com> <25499.990399116@redhat.com> <20010520211346.A6170@thyrsus.com> <6382.990427297@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <6382.990427297@redhat.com>; from dwmw2@infradead.org on Mon, May 21, 2001 at 07:41:37AM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org David Woodhouse : > Because it is evidently confusing the issue. Perhaps because it sounds like > you were intending to feed Linus large patches for 2.5.[12] which effect > _both_ changes. I'm going to give Linus the same installation kit the people working with CML2 have now. That will include both the CML2 engine and the rulesfiles. > Have patience - let the less contentious part of CML2 go in first, and then > we can deal with the other stuff later, once CML2 has been accepted (however > grudgingly in some cases) by developers. I don't think there is a "less contentious" part. The same people who bitched about the engine are now bitching about the changes I'm contemplating in the rulesfiles. It seems clear to me that their attitude, in general, has little to do with technical specifics of the engine or rulesets and everything to do with resistance to change in general and fear of losing control and/or hard-won implicit knowledge about the old system. I can sympathize with their upset, but I don't intend to let it stop me. And since I'm going to have these people angry at me unless I give up entirely, I figure I have little to lose by steaming ahead full. > > The engine is working. Why is it not yet time to discuss ruleset design > > and modes? > > For a man who claims to hack social systems, that's an incredibly naïve > question. You think so, eh? Heh. Experience has taught me that sometimes hacking social systems requires a certain amount of sheer bloodymindedness. See, I've already written off the chronic bellyachers. Since I can't please them without scrapping the whole plan, I'm going to ignore them. In particular, anybody who repeated "fsck Python..." after Linus ruled that Python is not an issue and Greg Banks announced the C implementation of CML2 has got a sufficiently severe case of rectocranial insertion that they've defined themselves out of the conversation. Instead I'll take my cues from people like you and Ray Knight and Tom Rini and Alan Cox and Martin Schwidefsky who are actually offering help and constructive criticism. (Arjan de Ven is trying but he's not up to speed on the language yet.) I trust you've noticed by now that I *do* listen very carefully in that situation, and I follow up with questions when I'm not sure what people are trying to tell me. I'll keep doing that. Eventually the bellyachers may get a message about what kind of behavior gains them influence and what kind loses them influence. That's a social-systems hack of a sort ;-). -- Eric S. Raymond I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC 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, 21 May 2001 05:55:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 05:55:44 -0400 Received: from smtp1.cern.ch ([137.138.128.38]:58641 "EHLO smtp1.cern.ch") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 05:55:31 -0400 To: Ben Ford Cc: linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <20010520185827.B16356@thune.mrc-home.com> <3B08B6B0.4010907@kalifornia.com> From: Jes Sorensen Date: 21 May 2001 11:55:15 +0200 In-Reply-To: Ben Ford's message of "Sun, 20 May 2001 23:33:20 -0700" Message-ID: User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 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 >>>>> "Ben" == Ben Ford writes: Ben> Mike Castle wrote: >> People who are going to be savvy enough to install a development >> 2.5.* kernel that is defining a new configuration utility are going >> to be savvy enough to install python. >> Ben> Not only that, but Alan said that somebody is rewriting it in C. No and yes, the Python 2 issue is not reasonable, the C version of it is. Hopefully with a proper C version, the Python 2 dependencies will go away completely and that part of the discussion becomes moot. The Python 2 one is a major issue, some people compile current kernels because thats all that exists for their hardware. Some people who are bringing up new architectures etc. wants to be self hosting but things like Perl and Python are not exactly the first things you build. You may not have threads, you may not have proper math support, maybe no shared libraries, but that wont stop you from getting gcc/binutils/bash going. The argument I got from Eric at the 2.5 kernel summit when I first brought this up was 'just configure your kernel on another machine and copy it over'. Thats extremely naiive, in some cases you do not have network nor floppy. You copy your sources over once (so you can hack on the network driver :), you don't want to have to rip out the disk every time you need a change to the .config because some obscure option doesn't compile and you hadn't noticed. It's just not that trivial. 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 ; Mon, 21 May 2001 07:05:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 07:05:35 -0400 Received: from t2.redhat.com ([199.183.24.243]:6392 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 07:05:18 -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: <20010521060440.A1738@thyrsus.com> In-Reply-To: <20010521060440.A1738@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> <20010520165952.A9622@devserv.devel.redhat.com> <25499.990399116@redhat.com> <20010520211346.A6170@thyrsus.com> <6382.990427297@redhat.com> To: esr@thyrsus.com Cc: Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 May 2001 12:05:12 +0100 Message-ID: <713.990443112@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org esr@thyrsus.com said: > I don't think there is a "less contentious" part. The same people who > bitched about the engine are now bitching about the changes I'm > contemplating in the rulesfiles. It seems clear to me that their > attitude, in general, has little to do with technical specifics of the > engine or rulesets and everything to do with resistance to change in > general and fear of losing control and/or hard-won implicit knowledge > about the old system. No. I didn't bitch (much) about CML2 - I'm fairly ambivalent. But I absolutely object to _unconditionally_ dumbing down the config options, because it would hide options which I would frequently want to enable. Introduce new novice modes if you wish - that seems sensible - but do not reduce the functionality and flexibility of configuration which is currently available. Any simplifications you make _must_ be dependent on the novice mode, and the default mode should allow the same choices as the current rules. More importantly, do not attempt to force through this change in policy by sneaking it into the 2.5.1 CML2 patch which introduces the new mechanism. The two are entirely orthogonal, and should remain separate. esr@thyrsus.com said: > I'm going to give Linus the same installation kit the people working > with CML2 have now. That will include both the CML2 engine and the > rulesfiles. Fine. What I'm asking is that you ensure that the CML2 rulesfiles at the time of the merge implement the dependencies present in the CML1 rulesfiles immediately prior to the merge. If you want to work on the change of policy right now, before CML2 is merged, then go ahead and do it in CML1. It's not difficult. The first step is to make CONFIG_*_ADVANCED depend on CONFIG_EXPERT, for example. Then get those changes merged into 2.5 before you merge CML2 - and you still keep the CML2 after the merge equivalent to the CML1 immediately before the merge. Otherwise, have patience and do it after CML2 is merged. All I'm asking is that you refrain from confusing the change in mechanism with the change in policy. That's not an unreasonable request, now is it? -- 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, 21 May 2001 07:34:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 07:34:05 -0400 Received: from turnover.lancs.ac.uk ([148.88.17.220]:11510 "EHLO helium.chromatix.org.uk") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 07:34:03 -0400 Message-Id: In-Reply-To: <3B08DC75.C466BA66@idb.hist.no> In-Reply-To: <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 May 2001 12:32:49 +0100 To: Helge Hafting , esr@thyrsus.com From: Jonathan Morton Subject: Re: Background to the argument about CML2 design philosophy Cc: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >> order to hold down ruleset complexity and simplify the user >> experience. The cost of deciding that the answer to that question is > >The user experience can be simplified by a NOVICE/EASY/SANE_DEFAULTS >option, and perhaps a HACKER option for the really strange >but _theoretically_ ok stuff. Having now briefly looked at the language constructs first-hand, I can see two ways to go about this: 1) Have a HACKER symbol which unsuppresses the "unusual" options, and suppresses the "generalised" ones (like: "build all the sound drivers for my hardware, as modules"). This is kinda how it would be implemented in CML1, cf. EXPERIMENTAL. 2) Have a HACKERS submenu system which contains all the derivations that could *possibly* be un-defaulted, and allow our intrepid hacker to explicitly force each to a value or leave unset. Leaving unset means the derivation holds, forcing it to a value will explicitly enable or disable the option along with any hard dependencies. Head this submenu system with a big banner that says "FOR EXPERTS ONLY", or suppress it using an "Experts" switch. Is there already a language construct to support the difference between a "derivation" and a "dependency"? Yes, it's the difference between "unless FOO==n default BAR==y" and "require FOO!=n implies BAR==y" respectively (or something to that effect, if my syntax is wrong flame gently please!). With that in mind, the front-end UI could implement Option 2 easily, by presenting a mode which automatically collects defaulted but otherwise hidden symbols, and reveals them to the user when set to "hacker" mode. I'm going to assume for now that CML2 saves two files - one storing a relatively small number of symbols (which is strictly limited to those explicitly set by the user), and one containing the full set for consumption by the Makefiles. If this is the case, then if a "hacker" type switches something explicitly then it'll stay there even if the default changes for that option in a future kernel. Meanwhile, Aunt Tillie gets the changed default option applied with no extra effort. "make oldconfig" might as well be a thing of the past for certain purposes, although it should still be kept as a way of reminding people what the new options are. Incidentally, in this scenario, if we have "enable driver for device FOOBAR [NEW] [y/m/N]:" then pressing Return should *not* mark the symbol as "explicitly set" but left alone because "user accepted the default". If they pressed "N", then that has the same effect but is saved explicitly for future kernels, regardless of any defaults change for that option. Hope this makes sense and I'm not being a stark raving loonie... -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi@cyberspace.org (not for attachments) big-mail: chromatix@penguinpowered.com uni-mail: j.d.morton@lancaster.ac.uk The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -----BEGIN GEEK CODE BLOCK----- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -----END GEEK CODE BLOCK----- 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, 21 May 2001 08:08:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 08:08:24 -0400 Received: from hall.mail.mindspring.net ([207.69.200.60]:60209 "EHLO hall.mail.mindspring.net") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 08:08:16 -0400 Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up From: Robert "M." Love To: Mike "A." Harris Cc: Jes Sorensen , John Cowan , esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: In-Reply-To: Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 21 May 2001 08:08:03 -0400 Message-Id: <990446886.1097.1.camel@phantasy> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 21 May 2001 02:11:39 -0400, Mike A. Harris wrote: > On 20 May 2001, Robert M. Love wrote: >>(on another note, about the coexist issue: am i going to have a python >>and python2 binary? so now the config tool will find which to use, ala >>the kgcc mess? great) > > For the record, the kgcc "mess" you speak of was used by > Conectiva, and I believe also by debian before adoption in Red > Hat Linux. It was about as good a solution as one could get for > the problem that it solved - the kernel being broken and unable > to build with our gcc-2.96. Just to head anyone off at the > pass... the kernel is fixed and now builds properly with > gcc-2.96. my view of the mess wasn't the fact RedHat used kgcc. i think that was a good move. i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95, gcc-2.91 etc. what is the cml2 parser going to do? search for my python2 binary because my python1 binary is my "standard" python? -- Robert M. Love rml@ufl.edu rml@tech9.net 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, 21 May 2001 08:16:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 08:16:25 -0400 Received: from t2.redhat.com ([199.183.24.243]:39928 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 08:16:10 -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: <20010518105353.A13684@thyrsus.com> <3B053B9B.23286E6C@redhat.com> <20010518112625.A14309@thyrsus.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> To: Jonathan Morton Cc: Helge Hafting , esr@thyrsus.com, linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 May 2001 13:15:23 +0100 Message-ID: <18583.990447323@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org chromi@cyberspace.org said: > Having now briefly looked at the language constructs first-hand, I > can see two ways to go about this: > 1) Have a HACKER symbol which unsuppresses the "unusual" options, and > suppresses the "generalised" ones > 2) Have a HACKERS submenu system which contains all the derivations > that could *possibly* be un-defaulted, and allow our intrepid hacker > to explicitly force each to a value or leave unset. I prefer the former, which is how it's already implemented in CML1. But the discussion of this is entirely unrelated to the discussion of CML2, and changes along these lines must not be forced into the kernel with the CML2 patch. If ESR is going to sneak policy changes into the kernel with the CML2 mechanism patch, I'm sure we all have patches we'd like him to add to it too, because we don't want to have to justify them on their own. :) -- 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, 21 May 2001 08:34:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 08:34:16 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:58383 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 08:34:01 -0400 Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up To: rml@tech9.net (Robert "M." Love) Date: Mon, 21 May 2001 13:29:25 +0100 (BST) Cc: mharris@opensourceadvocate.org (Mike "A." Harris), jes@sunsite.dk (Jes Sorensen), jcowan@reutershealth.com (John Cowan), esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <990446886.1097.1.camel@phantasy> from "Robert "M." Love" at May 21, 2001 08:08:03 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95, > gcc-2.91 etc. what is the cml2 parser going to do? search for my python2 This isnt a CML2 related problem. Problem 1: People who don't like the CML2 description Problem 2: People who don't like python Problem 3: People who don't like the tool design Problem 4: People who don't have python2 #1 is the important item #2 is fixed by rewriting tools in C #3 is fixed by writing alternative tools using CML2 - and if you cant its a bug in the CML2 language #4 is probably one for the LDPS/LSB and vendor people to discuss so we have an official path for python2 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, 21 May 2001 08:36:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 08:35:45 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:61199 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 08:35:40 -0400 Subject: Re: Background to the argument about CML2 design philosophy To: dwmw2@infradead.org (David Woodhouse) Date: Mon, 21 May 2001 13:31:10 +0100 (BST) Cc: chromi@cyberspace.org (Jonathan Morton), helgehaf@idb.hist.no (Helge Hafting), esr@thyrsus.com, linux-kernel@vger.kernel.org In-Reply-To: <18583.990447323@redhat.com> from "David Woodhouse" at May 21, 2001 01:15:23 PM X-Mailer: ELM [version 2.5 PL3] 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 > > 2) Have a HACKERS submenu system which contains all the derivations > > that could *possibly* be un-defaulted, and allow our intrepid hacker > > to explicitly force each to a value or leave unset. > > I prefer the former, which is how it's already implemented in CML1. Its called Debugging in CML1 in -ac for a reason btw. Because its called debugging I get plenty of reports that start "I dont know much about this but I turned on all the debugging options and now instead of hanging it says Oops 0xA5A5A5A5 ..." which are a lot more useful. Names matter a lot 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, 21 May 2001 11:19:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 11:18:56 -0400 Received: from ncc1701.cistron.net ([195.64.68.38]:37131 "EHLO ncc1701.cistron.net") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 11:18:44 -0400 From: wichert@cistron.nl (Wichert Akkerman) Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Date: 21 May 2001 17:18:31 +0200 Organization: Cistron Internet Services Message-ID: <9ebbk7$3uq$1@picard.cistron.nl> In-Reply-To: <990411054.773.0.camel@phantasy> To: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In article , Mike A. Harris wrote: >For the record, the kgcc "mess" you speak of was used by >Conectiva, and I believe also by debian Debian never had that mess. Wichert. -- _________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | wichert@cistron.nl http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- _________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | wichert@cistron.nl http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | 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, 21 May 2001 11:25:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 11:24:57 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:28420 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 11:24:49 -0400 Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up To: wichert@cistron.nl (Wichert Akkerman) Date: Mon, 21 May 2001 16:21:40 +0100 (BST) Cc: linux-kernel@vger.kernel.org In-Reply-To: <9ebbk7$3uq$1@picard.cistron.nl> from "Wichert Akkerman" at May 21, 2001 05:18:31 PM X-Mailer: ELM [version 2.5 PL3] 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 > Mike A. Harris wrote: > >For the record, the kgcc "mess" you speak of was used by > >Conectiva, and I believe also by debian > Debian never had that mess. Debians variant was gcc272 not kgcc. The 2.2.19 makefile knows about both of them From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 21 May 2001 11:44:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 11:44:01 -0400 Received: from cpe-24-221-152-185.az.sprintbbd.net ([24.221.152.185]:55564 "EHLO Opus.bloom.county") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 11:43:54 -0400 Date: Mon, 21 May 2001 08:36:02 -0700 From: Tom Rini To: Jes Sorensen Cc: Jakob ?stergaard , "Robert M. Love" , John Cowan , esr@thyrsus.com, linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010521083602.C9965@opus.bloom.county> In-Reply-To: <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> <3B054500.2090408@reutershealth.com> <990411054.773.0.camel@phantasy> <20010521043553.C20911@unthought.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from jes@sunsite.dk on Mon, May 21, 2001 at 11:58:34AM +0200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote: > >>>>> "Jakob" == Jakob ?stergaard writes: > > Jakob> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: > >> I think this is a very important point, and one I agree with. I > >> tend to let my distribution handle stuff like python. now, I use > >> RedHat's on-going devel, RawHide. it is not using python2. in > >> fact, since switching to python2 may break old stuff, I don't > >> expect python2 until 8.0. that wont be for 9 months. 90% of > >> RedHat's configuration tools, et al, are written in python1 and > >> they just are not going to change on someone's whim. > > Jakob> 2.6.0 isn't going to happen for at least a year or two. What's > Jakob> the problem ? > > Jakob> Want 2.5.X ? Get the tools too. > > Some people grab the latest devel kernels because thats all that works > on their hardware. And they can grab the latest tools too. Why is this a problem again? python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script uses undocumented things which did work in python1.5.x. But that's not as big of a problem since they can co-exist. Debian already does this (And thus CML2 already deals with python2 being called 'python2') and I wouldn't be supprised if the PowerTools python2 rpm someone pointed out makes them co-exist as well. Which brings up another point, RedHat (7.1?) and Debian/woody both have the option of having python2 around. Anyone know about mandrake? My point is that some dists are already dealing with python2. > Jakob> I'm in no position to push people around, but I think the > Jakob> whining about CML2 tool requirements is completely unjustified. > Jakob> If we required that everything worked with GCC 2.7.2 and nmake, > Jakob> where would we be today ? I'm a lot more worried about CML2 > Jakob> itself than about the tools it requires :) > > gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are > not. Well no, but python1 requires another 2k lines of python code or so. Eric, would it be easy/possible to go back to requiring python 1.5.x for CML2, since that is what many dists ship with? > Jakob> Whether CML2 requires python2 or not, the distributions will > Jakob> change. This is not about Eric pushing something down people's > Jakob> throats. Tools evolve, and new revisions introduce > Jakob> incompatibilities, but distributions still follow the > Jakob> evolution. Nobody ships perl4 today either. > > The point is that Eric has been trying to push distributions to ship > P2. Maybe, maybe not. Forgetting about the QA time and whatnot, there's good odds that all of the python scripts RedHat (for example) ships will just work with python2. I know one of the PPC dists didn't ship with python2 (which does have a lot of python bits to it) entirely because they were already in testing when it came out. It's not something the distros can switch to at a whim, but it's also something which shouldn't cause them problems when they do. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 21 May 2001 11:52:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 11:52:22 -0400 Received: from leibniz.math.psu.edu ([146.186.130.2]:8665 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 11:52:19 -0400 Date: Mon, 21 May 2001 11:52:17 -0400 (EDT) From: Alexander Viro To: Wichert Akkerman cc: linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: <9ebbk7$3uq$1@picard.cistron.nl> 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 21 May 2001, Wichert Akkerman wrote: > In article , > Mike A. Harris wrote: > >For the record, the kgcc "mess" you speak of was used by > >Conectiva, and I believe also by debian > > Debian never had that mess. I think that Mike refers to gcc272 being used as a kernel compiler for quite a while and gcc-2.95 being used the same way in -testing. having different compilers for kernel and userland is not pretty, but there's no way to avoid it at some points in cycle. 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, 21 May 2001 12:15:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 12:15:15 -0400 Received: from spc.esa.lanl.gov ([128.165.46.232]:21901 "HELO spc.esa.lanl.gov") by vger.kernel.org with SMTP id ; Mon, 21 May 2001 12:15:01 -0400 Content-Type: text/plain; charset=US-ASCII From: Steven Cole Reply-To: scole@lanl.gov To: Tom Rini Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Date: Mon, 21 May 2001 10:13:54 -0600 X-Mailer: KMail [version 1.2] In-Reply-To: <0105210958040I.10237@spc.esa.lanl.gov> <20010521090130.F9965@opus.bloom.county> In-Reply-To: <20010521090130.F9965@opus.bloom.county> Cc: linux-kernel@vger.kernel.org MIME-Version: 1.0 Message-Id: <0105211013540J.10237@spc.esa.lanl.gov> Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Monday 21 May 2001 10:01, Tom Rini wrote: > On Mon, May 21, 2001 at 09:58:04AM -0600, Steven Cole wrote: > > On Monday 21 May 2001 09:36, Tom Rini wrote: > > > Which brings up another point, RedHat (7.1?) and Debian/woody both have > > > the option of having python2 around. Anyone know about mandrake? My > > > point is that some dists are already dealing with python2. > > > > Hi Tom, > > I use Linux-Mandrake 8.0 now, and python2 is installed by default for a > > development workstation installation. I asked Mandrakesoft to also > > install the tkinter package (which was not installed by default in > > release candidate 1), and it appeared in LM 8.0 final, so if you like to > > use make xconfig with CML2, you can. > > Could you please send this to linux-kernel as well? :) At Tom's request, posting to lkml. Steven 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, 21 May 2001 12:22:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 12:22:05 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:36868 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 12:21:54 -0400 Date: Mon, 21 May 2001 12:24:42 -0400 From: "Eric S. Raymond" To: Tom Rini Cc: Jes Sorensen , Jakob ?stergaard , "Robert M. Love" , John Cowan , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010521122442.B3151@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Tom Rini , Jes Sorensen , Jakob ?stergaard , "Robert M. Love" , John Cowan , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: <20010513112543.A16121@thyrsus.com> <20010515173316.A8308@thyrsus.com> <3B054500.2090408@reutershealth.com> <990411054.773.0.camel@phantasy> <20010521043553.C20911@unthought.net> <20010521083602.C9965@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010521083602.C9965@opus.bloom.county>; from trini@kernel.crashing.org on Mon, May 21, 2001 at 08:36:02AM -0700 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Tom Rini : > python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script > uses undocumented things which did work in python1.5.x. That's true of the core language. The reason I moved to 2.0 was that there are library changes in 2.0 that enabled me to to cut CML2's in-kernel footprint substantially. > Which brings up another point, RedHat (7.1?) and Debian/woody both have the > option of having python2 around. Anyone know about mandrake? My point is > that some dists are already dealing with python2. Yes. By the time 2.5 forks, distros covering an estimated 85% of the market will carry python2 binaries which the CML2 install script will find automatically. By the time 2.6 forks, we're going to laugh if we ever remember that we thought this was an issue. > Eric, would it be easy/possible to go back to requiring python 1.5.x for > CML2, since that is what many dists ship with? It wouldn't be too difficult. But it would make the code heavier, and I'm not clear that it would make anybody happy who isn't already willing to deal with the design concept. -- Eric S. Raymond The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones 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, 21 May 2001 12:39:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 12:39:46 -0400 Received: from biglinux.tccw.wku.edu ([161.6.10.206]:19339 "EHLO biglinux.tccw.wku.edu") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 12:39:34 -0400 Date: Mon, 21 May 2001 11:39:30 -0500 (CDT) From: "Brent D. Norris" To: , Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > #2 is fixed by rewriting tools in C didn't Eric say that this has stalled though? Is that not the case? Brent Norris Executive Advisor -- WKU-Linux System Administrator -- WKU-Center for Biodiversity Best Mechanical 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, 21 May 2001 13:00:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 12:59:59 -0400 Received: from marine.sonic.net ([208.201.224.37]:10622 "HELO marine.sonic.net") by vger.kernel.org with SMTP id ; Mon, 21 May 2001 12:59:44 -0400 X-envelope-info: Date: Mon, 21 May 2001 09:59:38 -0700 From: Mike Castle To: linux-kernel@vger.kernel.org Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010521095938.A1529@thune.mrc-home.com> Reply-To: Mike Castle Mail-Followup-To: Mike Castle , linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B08B6B0.4010907@kalifornia.com> User-Agent: Mutt/1.3.18i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote: > Not only that, but Alan said that somebody is rewriting it in C. I'll believe it when I see it. mrc -- Mike Castle Life is like a clock: You can work constantly dalgoda@ix.netcom.com and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen 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, 21 May 2001 13:06:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 13:06:09 -0400 Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:31493 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 13:06:00 -0400 Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up To: dalgoda@ix.netcom.com Date: Mon, 21 May 2001 18:03:21 +0100 (BST) Cc: linux-kernel@vger.kernel.org In-Reply-To: <20010521095938.A1529@thune.mrc-home.com> from "Mike Castle" at May 21, 2001 09:59:38 AM X-Mailer: ELM [version 2.5 PL3] 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 > On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote: > > Not only that, but Alan said that somebody is rewriting it in C. > I'll believe it when I see it. and if not then obviously nobody hates the python one enough ;) 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, 21 May 2001 13:38:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 13:38:19 -0400 Received: from smtpnotes.altec.com ([209.149.164.10]:25869 "HELO smtpnotes.altec.com") by vger.kernel.org with SMTP id ; Mon, 21 May 2001 13:38:02 -0400 X-Lotus-FromDomain: ALTEC From: Wayne.Brown@altec.com To: esr@thyrsus.com cc: David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org Message-ID: <86256A53.0060ACF6.00@smtpnotes.altec.com> Date: Mon, 21 May 2001 12:36:48 -0500 Subject: Re: Background to the argument about CML2 design philosophy Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 05/21/2001 at 05:04:40 AM esr@thyrsus.com wrote: >See, I've already written off the chronic bellyachers. Since I can't >please them without scrapping the whole plan, I'm going to ignore >them. In particular, anybody who repeated "fsck Python..." after Linus >ruled that Python is not an issue and Greg Banks announced the C >implementation of CML2 has got a sufficiently severe case of >rectocranial insertion that they've defined themselves out of the >conversation. I probably qualify as one of the bellyachers. If so, I apologize. It was not my intention to disparage the work of Eric or anyone else involved in this project. Speaking from the perspective of a user of the CML tools, rather than as a developer, all I've been trying to say is this: When I type "make menuconfig" or "make oldconfig" in the future, I want to see the same interface and the same results that I've always seen, because it's always worked for me in the past. It really doesn't matter to me if, down underneath, this is being done by CML1, CML2, or a little man in my computer who slaughters chickens and reads their entrails for omens to determine dependencies. Right now I can grab a new -pre or -ac patch, use oldconfig, and have a compile going in a few minutes, without knowing or caring about the details of the config process. In the rare case that a patch breaks an existing driver, it takes only a couple of minutes with menuconfig to disable that driver and compile without it, and then put it back in when it's fixed. And when, every once in a great while, I decide to scrap my .config and start over, I can fly through all the menuconfig options very quickly and make my customary selections almost without thinking about it. I just want to be able to keep using the tools in this way. If that's not going to be possible... well, I'll adapt. But from my point of view, learning a new set of tools just to keep doing the same things I've always done isn't a pleasant prospect. I understand that changes may be necessary to meet others' needs, but I'd like to see those changes made without affecting the way my own needs are met. I'm off my soapbox now and won't bellyache about it any further. Wayne From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 21 May 2001 13:46:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 13:46:00 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:64261 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 13:45:45 -0400 Date: Mon, 21 May 2001 13:48:55 -0400 From: "Eric S. Raymond" To: "Brent D. Norris" Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up Message-ID: <20010521134855.A11361@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , "Brent D. Norris" , linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from brent@biglinux.tccw.wku.edu on Mon, May 21, 2001 at 11:39:30AM -0500 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Brent D. Norris : > didn't Eric say that this has stalled though? Is that not the case? Nope. Greg is still working. He got the first version of the theorem prover working recently. -- Eric S. Raymond A wise and frugal government, which shall restrain men from injuring one another, which shall leave them otherwise free to regulate their own pursuits of industry and improvement, and shall not take from the mouth of labor the bread it has earned. This is the sum of good government, and all that is necessary to close the circle of our felicities. -- Thomas Jefferson, in his 1801 inaugural address 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, 21 May 2001 13:56:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 13:56:19 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:1542 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 13:56:03 -0400 Date: Mon, 21 May 2001 13:58:57 -0400 From: "Eric S. Raymond" To: Wayne.Brown@altec.com Cc: David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Message-ID: <20010521135857.B11361@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Wayne.Brown@altec.com, David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <86256A53.0060ACF6.00@smtpnotes.altec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86256A53.0060ACF6.00@smtpnotes.altec.com>; from Wayne.Brown@altec.com on Mon, May 21, 2001 at 12:36:48PM -0500 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Wayne.Brown@altec.com : > Speaking from the perspective of a user of the CML tools, rather > than as a developer, all I've been trying to say is this: When I > type "make menuconfig" or "make oldconfig" in the future, I want to > see the same interface and the same results that I've always seen, > because it's always worked for me in the past. Visual details will differ, but I've been careful about maintaining functional compatibility. There was a phase of the development during which I was mostly processing feature requests from people who wanted features of the old system that I had not properly understood (such as the NEW tag). That phase ended almost a month ago. Nobody who has actually tried the CML2 tools more recently has reported that the UI changes present any difficulty. CML2 drops its configuration results in the same place, in the same formats, as CML1. So you should in fact be able to type `make menuconfig' and `make oldconfig' with good results. Have you actually tried this? -- Eric S. Raymond The right of the citizens to keep and bear arms has justly been considered as the palladium of the liberties of a republic; since it offers a strong moral check against usurpation and arbitrary power of rulers; and will generally, even if these are successful in the first instance, enable the people to resist and triumph over them." -- Supreme Court Justice Joseph Story of the John Marshall Court 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, 21 May 2001 15:01:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 15:01:28 -0400 Received: from fenrus.demon.co.uk ([158.152.228.152]:6025 "EHLO amadeus.home.nl") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 15:01:22 -0400 Message-Id: Date: Mon, 21 May 2001 08:21:01 +0100 (BST) From: arjan@fenrus.demon.nl To: Mike Castle Subject: Re: [kbuild-devel] Re: CML2 design philosophy heads-up cc: linux-kernel@vger.kernel.org In-Reply-To: <20010520185827.B16356@thune.mrc-home.com> X-Newsgroups: fenrus.linux.kernel User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (Linux/2.4.3-6.0.1 (i586)) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In article <20010520185827.B16356@thune.mrc-home.com> you wrote: > On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: >> distributions). 18 months is more realistic for it to be deployed >> widely enough. > People who are going to be savvy enough to install a development 2.5.* > kernel that is defining a new configuration utility are going to be savvy > enough to install python. In the first months, yes. Once we freeze you've just lost a major part of your testersbase... 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, 21 May 2001 15:07:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 15:07:08 -0400 Received: from smtpnotes.altec.com ([209.149.164.10]:43272 "HELO smtpnotes.altec.com") by vger.kernel.org with SMTP id ; Mon, 21 May 2001 15:06:59 -0400 X-Lotus-FromDomain: ALTEC From: Wayne.Brown@altec.com To: esr@thyrsus.com cc: David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org Message-ID: <86256A53.0068D169.00@smtpnotes.altec.com> Date: Mon, 21 May 2001 14:05:27 -0500 Subject: Re: Background to the argument about CML2 design philosophy Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 05/21/2001 at 12:58:57 esr@thyrsus.com wrote: >CML2 drops its configuration results in the same place, in the same >formats, as CML1. So you should in fact be able to type `make menuconfig' >and `make oldconfig' with good results. Have you actually tried this? No, I haven't tried it yet. I usually wait for things like this to be included in Linus' or Alan's kernels before trying them. In this case, I might have tried it by now but I only have Python 1.5.2 on my system and don't want to upgrade it until/unless it's absolutely necessary. So I probably won't see CML2 until Linus puts it in 2.5. My comments have been based on your descriptions of it on lkml. Wayne From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 21 May 2001 16:00:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 16:00:36 -0400 Received: from fungus.teststation.com ([212.32.186.211]:63185 "EHLO fungus.svenskatest.se") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 16:00:27 -0400 Date: Mon, 21 May 2001 22:00:07 +0200 (CEST) From: Urban Widmark To: "Eric S. Raymond" cc: , David Woodhouse , Arjan van de Ven , Subject: Re: Background to the argument about CML2 design philosophy In-Reply-To: <20010521135857.B11361@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 21 May 2001, Eric S. Raymond wrote: > the NEW tag). That phase ended almost a month ago. Nobody who has > actually tried the CML2 tools more recently has reported that the UI > changes present any difficulty. What happened with the discussion on configurable colors in make menuconfig? Darkblue on black as frozen options get isn't exactly optimal ... at least not for my eyes. Being next to a bold, white text doesn't help either. > CML2 drops its configuration results in the same place, in the same > formats, as CML1. So you should in fact be able to type `make menuconfig' > and `make oldconfig' with good results. Have you actually tried this? It works for me, but anyone testing this should know that the CML2 tools read "config.out" if it finds one. So people that do things like: make mrproper ; cp ../.config-2.4 .config ; make oldconfig will have to change to copying config.out instead. Doing like this sort of works* if there is no config.out, otherwise it does not (as it uses the config.out). Saying that the config result ends up in the same place and same format is somewhat misleading, you do get a copy in the CML1 output format but the tools doesn't care about that if it can find a file in the new format. *) "Sort of works", since doing like I do will cause you to get a lot of questions that you have already answered. That appears to be a one-time problem as 'oldconfig' does not read "# CONFIG_FOO is not set" as "no". Would be nice if it did. make mrproper doesn't remove config.out. It should since that's what it does with .config* files. Not sure if it should remove the rules.out file also, but I think it should as the idea(?) with mrproper is to clean up anything that is generated. /Urban 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, 21 May 2001 16:41:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 16:41:16 -0400 Received: from alpo.casc.com ([152.148.10.6]:19904 "EHLO alpo.casc.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 16:41:04 -0400 From: John Stoffel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15113.31946.548249.53012@gargle.gargle.HOWL> Date: Mon, 21 May 2001 16:38:34 -0400 To: linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy In-Reply-To: <25499.990399116@redhat.com> In-Reply-To: <20010520165952.A9622@devserv.devel.redhat.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> <25499.990399116@redhat.com> X-Mailer: VM 6.90 under Emacs 20.6.1 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org David> Actually, the current system has both types. As well as the David> "hard" dependencies, we also have stuff like David> CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED, David> CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED, David> etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too. David> These things have already been set up in the way that David> developers prefer it. *some* developers prefer it. Not all. David> CML2 allows us to be more flexible than we were before, and David> that can be a good thing when used in moderation. But please, David> for the sake of the sanity of all concerned, do things one at a David> time. Provide for merging into 2.5 a set of rules which David> reproduce the existing CML1 behaviour in this respect. Can you define what you mean here? It's not really clear to me, and I suspect others. David> Eric, if you want to make further changes later to introduce David> new 'modes' for kernel configuration, that's an entirely David> separate issue. Please don't confuse the issue by trying to do David> it at the same time as introducing CML2. I don't think he is introducing new modes, he's just trying to make sure that you can't create a .config which is broken. Part of my complaint early on was that it would just barf on a config it thought wasn't legall, and just drop me to the 'vi' level. I don't think this is acceptable because you (CML2 or CMLxxxx) should be able to prompt the user for a suggested fix. David> CONFIG_AUNT_TILLIE does not require CML2. Correct. David> CML2 does not require CONFIG_AUNT_TILLIE. Correct. And never has offered it either! David> Let's not talk about CONFIG_AUNT_TILLIE any more, or change the David> existing behaviour of config options to make that the default, David> until we've settled the discussion about CML2. I think it comes down to people who just want one or more of: - the existing interface of vi .config; make oldconfig - fear that CML2 won't let them make crazy configurations, such as an 8-way SMP box with ISA. Can't see how CML2 would restrict this choice myself. - Don't want to install python 2.x for a kernel upgrade. - fear that some configuration corner case will be handled wrong for a strange (read not common) system config. All that CML2 does is enforce dependencies in the configuration language. You can't make a .config which conflicts. Admittedly there's nothing stopping you from hacking it with vi after the fact, but why? If you run into a case where you have a config which would work, but CML2 doesn't let you, why don't you fix the grammar instead of saying CML2 is wrong? Let's not confuse these two issues as well. John 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, 21 May 2001 19:12:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 19:12:43 -0400 Received: from turnover.lancs.ac.uk ([148.88.17.220]:50166 "EHLO helium.chromatix.org.uk") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 19:12:29 -0400 Message-Id: In-Reply-To: <15113.31946.548249.53012@gargle.gargle.HOWL> In-Reply-To: <25499.990399116@redhat.com> <20010520165952.A9622@devserv.devel.redhat.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> <25499.990399116@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 May 2001 00:00:35 +0100 To: John Stoffel , linux-kernel@vger.kernel.org From: Jonathan Morton Subject: Re: Background to the argument about CML2 design philosophy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >If you run into a case where you have a config which would work, but >CML2 doesn't let you, why don't you fix the grammar instead of saying >CML2 is wrong? Let's not confuse these two issues as well. Strongly agree. Especially since I'm pushing for an explicit recognition of the difference between a hard dependancy and a soft derivation. The latter can be over-ridden safely by someone who knows what he's after. The former will cause a miscompile. -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi@cyberspace.org (not for attachments) big-mail: chromatix@penguinpowered.com uni-mail: j.d.morton@lancaster.ac.uk The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -----BEGIN GEEK CODE BLOCK----- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -----END GEEK CODE BLOCK----- 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, 21 May 2001 19:14:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 19:14:42 -0400 Received: from turnover.lancs.ac.uk ([148.88.17.220]:44538 "EHLO helium.chromatix.org.uk") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 19:14:30 -0400 Message-Id: In-Reply-To: In-Reply-To: <18583.990447323@redhat.com> from "David Woodhouse" at May 21, 2001 01:15:23 PM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 May 2001 00:11:21 +0100 To: Alan Cox , dwmw2@infradead.org (David Woodhouse) From: Jonathan Morton Subject: Re: Background to the argument about CML2 design philosophy Cc: helgehaf@idb.hist.no (Helge Hafting), esr@thyrsus.com, linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >> > 2) Have a HACKERS submenu system which contains all the derivations >> > that could *possibly* be un-defaulted, and allow our intrepid hacker >> > to explicitly force each to a value or leave unset. >> >> I prefer the former, which is how it's already implemented in CML1. > >Its called Debugging in CML1 in -ac for a reason btw. Because its called >debugging I get plenty of reports that start I think "Debugging" and "HACKERS" go in separate categories. "Debugging" is for pinpointing problems in the *same* configuration, "HACKERS" is for making *different* configurations. Not that I really care what it's called, provided the concept gets thought about. If I select MAC68K and SCSI, it's perfectly reasonable for the two "standard" SCSI drivers to be compiled-in for most people. But if I run into a PowerBook 190 or Quadra 840av (which, if I'm not much mistaken, don't use the standard chipsets - and I happen to have access to both of them), I might want to turn them off and turn on my own hacked-up driver. Or I might want to turn off the one I'm not using, to save space on that old spare 4Mb Classic II. And in fact this is a non-issue at present - the SCSI rulesfile has "unless MAC suppress MAC_SCSI SCSI_MAC_ESP" and NOTHING which forces MAC_SCSI and SCS_MAC_ESP to "on" if I'm running a Mac. As far as I can tell, both would default to "off", and are merely hidden if I happen not to be running such a machine. For the moment, I'll be happy if the rulesfile remains similar in function to CML1 but with the added intelligence CML2 brings with it by default. If in the future someone wants to add "Aunt Tillie" features, then sensible defaults can easily be added and over-ridden. I think I'd like CML2 to remember which options are explicitly set and which ones I left alone (if it doesn't do so already) - that will go a long way towards helping Aunt Tillie in the long run. -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi@cyberspace.org (not for attachments) big-mail: chromatix@penguinpowered.com uni-mail: j.d.morton@lancaster.ac.uk The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -----BEGIN GEEK CODE BLOCK----- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -----END GEEK CODE BLOCK----- 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, 21 May 2001 21:00:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 20:59:56 -0400 Received: from deliverator.sgi.com ([204.94.214.10]:64783 "EHLO deliverator.sgi.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 20:59:48 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: John Stoffel cc: linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy In-Reply-To: Your message of "Mon, 21 May 2001 16:38:34 -0400." <15113.31946.548249.53012@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 May 2001 10:59:04 +1000 Message-ID: <2436.990493144@kao2.melbourne.sgi.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 21 May 2001 16:38:34 -0400, John Stoffel wrote: >All that CML2 does is enforce dependencies in the configuration >language. You can't make a .config which conflicts. Admittedly >there's nothing stopping you from hacking it with vi after the fact, >but why? CML2 will not stop you hacking .config by hand. But the 2.5 makefile rewrite will, because we have had too many bug reports caused by people who hand edited .config, did not revalidate it and generated invalid kernels. Yes, you can hand edit .config. No, you cannot compile until .config has been (re-)validated. # Not a real dependency, this checks for hand editing of .config. $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config @echo Your .config is newer than include/linux/autoconf.h, this should not happen. @echo Always run make one of "{menu,old,x}config" after manually updating .config. @/bin/false And before people complain: Don't create a config that violates the CML rules, correct the CML rules, the Makefiles and the source so .config is valid. The kernel build requires a valid .config. 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, 21 May 2001 22:39:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 May 2001 22:39:37 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:4872 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Mon, 21 May 2001 22:39:25 -0400 Date: Mon, 21 May 2001 22:42:13 -0400 From: "Eric S. Raymond" To: Urban Widmark Cc: Wayne.Brown@altec.com, David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Message-ID: <20010521224213.I21408@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Urban Widmark , Wayne.Brown@altec.com, David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010521135857.B11361@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from urban@teststation.com on Mon, May 21, 2001 at 10:00:07PM +0200 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 Urban Widmark : > What happened with the discussion on configurable colors in make > menuconfig? Darkblue on black as frozen options get isn't exactly optimal > ... at least not for my eyes. Being next to a bold, white text doesn't > help either. Nobody could come up with a way to support configurable colors that didn't seem like way more trouble than it was worth. -- Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 22 May 2001 09:46:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 22 May 2001 09:46:40 -0400 Received: from t2.redhat.com ([199.183.24.243]:13041 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Tue, 22 May 2001 09:46:28 -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: <15113.31946.548249.53012@gargle.gargle.HOWL> In-Reply-To: <15113.31946.548249.53012@gargle.gargle.HOWL> <20010520165952.A9622@devserv.devel.redhat.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> <25499.990399116@redhat.com> To: John Stoffel Cc: linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 May 2001 14:45:53 +0100 Message-ID: <7938.990539153@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org stoffel@casc.com said: > David> for the sake of the sanity of all concerned, do things one at a > David> time. Provide for merging into 2.5 a set of rules which > David> reproduce the existing CML1 behaviour in this respect. > Can you define what you mean here? It's not really clear to me, and I > suspect others. You appear to be responding to my email, yet you did not do me the courtesy of including me in the recipients. Should I assume you're asking this question of me directly, or was it a rhetorical question? stoffel@casc.com said: > I don't think he is introducing new modes, he's just trying to make > sure that you can't create a .config which is broken. Good. You should be prevented from creating a .config which is broken, and the existing CML1 rules attempt to achieve this. CML2 should continue to do so, and indeed should do so more effectively and flexibly. > - fear that CML2 won't let them make crazy configurations, such as an > 8-way SMP box with ISA. Can't see how CML2 would restrict this > choice myself. I do not fear that CML2 itself will prevent these 'crazy' configurations. That is why I said that the issue is entirely orthogonal to CML2. However, it would obviously be possible to introduce new dependencies to the rules files -- either CML1 or CML2 -- which do prevent such configurations. What I fear is that such new, unwanted, dependencies may be introduced to the kernel -- either by accident or by deception -- in the large patch which introduces CML2 and converts the existing rules files. Subtle changes to the behaviour could easily go unnoticed in such a large patch. I am asking that such a deception should not be attempted. The CML2 rules introduced to 2.5.n should exactly represent the behaviour of the CML1 rules in 2.5.(n-1). Changes to the policy represented within the rules files can then be presented afterwards, and should be considered entirely separate to the change in mechanism. stoffel@casc.com said: > If you run into a case where you have a config which would work, but > CML2 doesn't let you, why don't you fix the grammar instead of saying > CML2 is wrong? I think you are being overly defensive. I was not saying that CML2 is wrong. I said that I was ambivalent about CML2, and the point I'm talking about is entirely irrelevant to CML2 - except that I'm trying to make sure that the large CML2 patch is not used as a vehicle for sneaking other, more contentious, changes into the kernel. I want to discuss those changes _separately_ once the CML2 issue is out of the way, because otherwise people just won't bother to read what I said, and will assume I'm arguing against CML2 itself. -- 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 ; Tue, 22 May 2001 10:31:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 22 May 2001 10:31:33 -0400 Received: from elektra.higherplane.net ([203.37.52.137]:56027 "EHLO elektra.higherplane.net") by vger.kernel.org with ESMTP id ; Tue, 22 May 2001 10:31:24 -0400 Date: Wed, 23 May 2001 00:42:57 +1000 From: john slee To: Urban Widmark Cc: "Eric S. Raymond" , Wayne.Brown@altec.com, David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Message-ID: <20010523004257.C5779@higherplane.net> In-Reply-To: <20010521135857.B11361@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from urban@teststation.com on Mon, May 21, 2001 at 10:00:07PM +0200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote: > On Mon, 21 May 2001, Eric S. Raymond wrote: > > > the NEW tag). That phase ended almost a month ago. Nobody who has > > actually tried the CML2 tools more recently has reported that the UI > > changes present any difficulty. > > What happened with the discussion on configurable colors in make > menuconfig? Darkblue on black as frozen options get isn't exactly optimal > ... at least not for my eyes. Being next to a bold, white text doesn't > help either. if you don't like dark blue on black, change your terminal colours. then you won't find it hard to read in other applications either. it's also far less effort this way... j. -- "Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 22 May 2001 10:33:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 22 May 2001 10:33:35 -0400 Received: from humbolt.nl.linux.org ([131.211.28.48]:4619 "EHLO humbolt.nl.linux.org") by vger.kernel.org with ESMTP id ; Tue, 22 May 2001 10:33:21 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Keith Owens , John Stoffel Subject: Re: Background to the argument about CML2 design philosophy Date: Tue, 22 May 2001 11:24:54 +0200 X-Mailer: KMail [version 1.2] Cc: linux-kernel@vger.kernel.org In-Reply-To: <2436.990493144@kao2.melbourne.sgi.com> In-Reply-To: <2436.990493144@kao2.melbourne.sgi.com> MIME-Version: 1.0 Message-Id: <01052211245404.06233@starship> Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 22 May 2001 02:59, Keith Owens wrote: > > # Not a real dependency, this checks for hand editing of .config. > $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config > @echo Your .config is newer than include/linux/autoconf.h, > this should not happen. @echo Always run make one of > "{menu,old,x}config" after manually updating .config. @/bin/false Ahem. What is wrong with revalidating it automatically? *Then* if there's a problem, bother the user. "No news is good news". -- Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 22 May 2001 12:24:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 22 May 2001 12:24:45 -0400 Received: from alpo.casc.com ([152.148.10.6]:38612 "EHLO alpo.casc.com") by vger.kernel.org with ESMTP id ; Tue, 22 May 2001 12:24:33 -0400 From: John Stoffel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15114.37415.204391.420484@gargle.gargle.HOWL> Date: Tue, 22 May 2001 12:21:59 -0400 To: David Woodhouse Cc: John Stoffel , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy In-Reply-To: <7938.990539153@redhat.com> In-Reply-To: <15113.31946.548249.53012@gargle.gargle.HOWL> <20010520165952.A9622@devserv.devel.redhat.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> <25499.990399116@redhat.com> <7938.990539153@redhat.com> X-Mailer: VM 6.91 under Emacs 20.6.1 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org David> You appear to be responding to my email, yet you did not do me David> the courtesy of including me in the recipients. Should I assume David> you're asking this question of me directly, or was it a David> rhetorical question? It was more of an attempt to cutdown on the number of recipients, not any attempt to keep you out of the discussion. This time, I've left the recipients alone. David> Good. You should be prevented from creating a .config which is David> broken, and the existing CML1 rules attempt to achieve David> this. We are in agreement here, though I doubt that the CML1 ruleset really achieves this goal in any serious way. It just doesn't have the power. David> CML2 should continue to do so, and indeed should do so more David> effectively and flexibly. Agreed. David> What I fear is that such new, unwanted, dependencies may be David> introduced to the kernel -- either by accident or by deception David> -- in the large patch which introduces CML2 and converts the David> existing rules files. Subtle changes to the behaviour could David> easily go unnoticed in such a large patch. I don't agree with this, since the current CML1 scheme has wierd, unwanted and wrong dependencies already, which can't (or haven't) been found. Since it would be put in during the 2.5.x branching, it's expected that things will/can/should break, so I don't think there will be any dire consequences. David> I think you are being overly defensive. I was not saying that David> CML2 is wrong. I said that I was ambivalent about CML2, and the David> point I'm talking about is entirely irrelevant to CML2 - except David> that I'm trying to make sure that the large CML2 patch is not David> used as a vehicle for sneaking other, more contentious, changes David> into the kernel. Such as what? Do you have any examples here? David> I want to discuss those changes _separately_ once the CML2 David> issue is out of the way, because otherwise people just won't David> bother to read what I said, and will assume I'm arguing against David> CML2 itself. This is the first time you have come out and explicitly *said* what you are for and against in CML2. People need to be clear about what they are talking about. As a general question for all readers, how many are against CML2 in any shape or form? How many are like David, and don't mind CML2, but are worried about dependency issues? How many think CML2 and it's dependencies will be a step forward in kernel configuration? Thanks, John From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 22 May 2001 13:18:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 22 May 2001 13:18:45 -0400 Received: from t2.redhat.com ([199.183.24.243]:28659 "EHLO passion.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Tue, 22 May 2001 13:18: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: <15114.37415.204391.420484@gargle.gargle.HOWL> In-Reply-To: <15114.37415.204391.420484@gargle.gargle.HOWL> <15113.31946.548249.53012@gargle.gargle.HOWL> <20010520165952.A9622@devserv.devel.redhat.com> <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <18686.990380851@redhat.com> <20010520164700.H4488@thyrsus.com> <25499.990399116@redhat.com> <7938.990539153@redhat.com> To: John Stoffel Cc: linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Date: Tue, 22 May 2001 18:17:58 +0100 Message-ID: <5080.990551878@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org stoffel@casc.com said: > I don't agree with this, since the current CML1 scheme has wierd, > unwanted and wrong dependencies already, which can't (or haven't) been > found. Since it would be put in during the 2.5.x branching, it's > expected that things will/can/should break, so I don't think there > will be any dire consequences. OK, I obviously don't expect the behaviour to be _exactly_ identical. If CML2 allows the authors' intent to be more closely adhered to, that's a good thing. But if the CML2 files exhibit behaviour which was clearly _not_ the intention of the original CML1, that is a change which should be made under separate cover. > Such as what? Do you have any examples here? The MAC/SCSI dependencies, which it seems were 'simplified' at the cost of preventing certain combinations which were unlikely but valid, and which it was possible to select with the original rules. Also of course the whole class of dependencies which people are talking about introducing for the benefit of the hypothetical Aunt Tillie. I don't know how many, if any, of this kind of changes are _actually_ made in the current CML2 rules files - what I'm saying is that there _should_ be none. Such large changes to the policy are entirely unrelated to CML2 itself, and should be discussed separately. If your response to this is "But there are no such changes, you misunderstood the MAC/SCSI dependency conversation and the Aunt Tillie stuff was all hypothetical, what are you talking about?", then good - that's precisely the answer I was after. All I'm asking for is a clear agreement that within reason, the behaviour of the CML2 rules files immediately after CML2 is merged will match the intended behaviour of the CML1 rules prior to the merge. -- 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 ; Tue, 22 May 2001 13:30:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 22 May 2001 13:30:16 -0400 Received: from humbolt.nl.linux.org ([131.211.28.48]:28943 "EHLO humbolt.nl.linux.org") by vger.kernel.org with ESMTP id ; Tue, 22 May 2001 13:30:05 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: john slee , Urban Widmark Subject: Re: Background to the argument about CML2 design philosophy Date: Tue, 22 May 2001 19:28:20 +0200 X-Mailer: KMail [version 1.2] Cc: "Eric S. Raymond" , Wayne.Brown@altec.com, David Woodhouse , Arjan van de Ven , linux-kernel@vger.kernel.org In-Reply-To: <20010521135857.B11361@thyrsus.com> <20010523004257.C5779@higherplane.net> In-Reply-To: <20010523004257.C5779@higherplane.net> MIME-Version: 1.0 Message-Id: <0105221928200D.06233@starship> Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 22 May 2001 16:42, john slee wrote: > On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote: > > On Mon, 21 May 2001, Eric S. Raymond wrote: > > > the NEW tag). That phase ended almost a month ago. Nobody who > > > has actually tried the CML2 tools more recently has reported that > > > the UI changes present any difficulty. > > > > What happened with the discussion on configurable colors in make > > menuconfig? Darkblue on black as frozen options get isn't exactly > > optimal ... at least not for my eyes. Being next to a bold, white > > text doesn't help either. > > if you don't like dark blue on black, change your terminal colours. > then you won't find it hard to read in other applications either. On the first day of my graduate course 'Advanced Topics in Computer Graphics' the professor walked in and wrote on the blackboard "Never Use Blue on Black". Yes, we had blackboards then. No, our eyes have not evolved since then. ;-) -- Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 22 May 2001 16:36:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 22 May 2001 16:36:27 -0400 Received: from snark.tuxedo.org ([207.106.50.26]:22021 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Tue, 22 May 2001 16:36:13 -0400 Date: Tue, 22 May 2001 16:38:45 -0400 From: "Eric S. Raymond" To: Jonathan Morton Cc: Helge Hafting , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy Message-ID: <20010522163845.B3880@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Jonathan Morton , Helge Hafting , linux-kernel@vger.kernel.org In-Reply-To: <20010518113726.A29617@devserv.devel.redhat.com> <20010518114922.C14309@thyrsus.com> <8485.990357599@redhat.com> <20010520111856.C3431@thyrsus.com> <15823.990372866@redhat.com> <20010520114411.A3600@thyrsus.com> <16267.990374170@redhat.com> <20010520131457.A3769@thyrsus.com> <3B08DC75.C466BA66@idb.hist.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from chromi@cyberspace.org on Mon, May 21, 2001 at 12:32:49PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jonathan Morton : > I'm going to assume for now that CML2 saves two files - one storing a > relatively small number of symbols (which is strictly limited to those > explicitly set by the user), and one containing the full set for > consumption by the Makefiles. No, that's not the case. Would it be too much to ask that you learn how the existing language works brfore proposing improvements? -- Eric S. Raymond The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, "My First Impression of the U.S.A.", 1921 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 22 May 2001 21:52:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 22 May 2001 21:52:28 -0400 Received: from deliverator.sgi.com ([204.94.214.10]:41826 "EHLO deliverator.sgi.com") by vger.kernel.org with ESMTP id ; Tue, 22 May 2001 21:52:22 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Daniel Phillips cc: John Stoffel , linux-kernel@vger.kernel.org Subject: Re: Background to the argument about CML2 design philosophy In-Reply-To: Your message of "Tue, 22 May 2001 11:24:54 +0200." <01052211245404.06233@starship> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 11:51:31 +1000 Message-ID: <5810.990582691@kao2.melbourne.sgi.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 22 May 2001 11:24:54 +0200, Daniel Phillips wrote: >On Tuesday 22 May 2001 02:59, Keith Owens wrote: >> # Not a real dependency, this checks for hand editing of .config. >> $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config >> @echo Your .config is newer than include/linux/autoconf.h, >> this should not happen. @echo Always run make one of >> "{menu,old,x}config" after manually updating .config. @/bin/false > >Ahem. What is wrong with revalidating it automatically? *Then* if there's a >problem, bother the user. Revalidate using which tool? Did the user even mean to edit .config? This is a case where the user has to decide what to do.