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 ; Sun, 13 May 2001 12:45:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 13 May 2001 12:45:05 -0400 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:58894 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id ; Sun, 13 May 2001 12:44:54 -0400 Date: Sun, 13 May 2001 17:44:29 +0100 From: Matthew Wilcox To: esr@thyrsus.com Cc: linux-kernel@vger.kernel.org Subject: Re: CML2 design philosophy heads-up Message-ID: <20010513174429.A5904@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Eric S. Raymond wrote: > 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, you're trying to do too much too quickly. Wait until 2.5 to clean stuff up. That's what the rest of us have to do, even for some things which are real bugs rather than infelicities in the current design. You can't treat this as an all-or-nothing deal. Some of your ideas for CML2 are right, and some aren't. Get the non-controversial bits in, then fight over the ideas that're worth fighting for. Yes, CML2 enables a more task-based than hardware-based approach, and I think that's generally a good thing; but I do believe that this isn't going to be suitable for everyone. Let's work up to it gradually. -- One of the most insidious things the CIA Communists did when they took over Unistat was to change the Constitution. The original Constitution, having been written by a group of intellectual libertines and Freemasons in the eighteenth century, included an amendment which declared: A self-regulated sex life being necessary to the happiness of a citizen, the right of people to keep and enjoy pornography shall not be abridged. This amendment had been suggested by Thomas Jefferson, who had over nine hundred Black concubines, and Benjamin Franklin, a member of the Hell Fire Club, which had the largest collection of erotic books and art in the Western world at that time. The Communists changed the amendment to read: A well-regulated militia being necessary to the security of a free state, the right of the citizens to keep and bear arms shall not be abridged. All documents and textbooks were changed, so that nobody would be able to find out what the amendment had originally said. Then the Communists set up a front organisation, the National Rifle Association, to encourage the wide usage of guns of all sorts and to battle any attempt to control guns as "unconstitutional." Thus, they guaranteed that the murder rate in Unistat would always be the highest in the world. This kept the citizens in perpetual anxiety about their safety both on the streets and in their homes. The citizens then tolerated the rapid growth of the Police State, which controlled almost everything, except the sale of guns, the chief cause of crime. -- Robert Anson Wilson in the Schroedinger's Cat Trilogy 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 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: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: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 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: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: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: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 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 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 18:18:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 May 2001 18:18:32 -0400 Received: from nat-pool-meridian.redhat.com ([199.183.24.200]:9062 "EHLO devserv.devel.redhat.com") by vger.kernel.org with ESMTP id ; Fri, 18 May 2001 18:18:14 -0400 Date: Fri, 18 May 2001 18:18:14 -0400 From: Pete Zaitcev Message-Id: <200105182218.f4IMIE910681@devserv.devel.redhat.com> To: Subject: Re: CML2 design philosophy heads-up In-Reply-To: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > 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? I always do "vi .config", then "make oldconfig", because it is very convinient, simple, and flexible way to do it. For instance, it is very easy to store a pile of configs for different kernels, very easy do diff them (with -u and without). I do not have Python installed on any of my machines. The right way to handle the CML2 problem, IMHO, is to have a C implementation of Python part without curses, tcl, and other crap. Half of ESR's justification is "dynatic loading of components and recovery from failure to load them", which goes away if we do not support extras like curses. Another half was GC, which is just a convinience for a project of CML's size. -- 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 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 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