Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 16 Feb 2002 11:18:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 16 Feb 2002 11:18:17 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:31752 "EHLO golux.thyrsus.com") by vger.kernel.org with ESMTP id ; Sat, 16 Feb 2002 11:17:58 -0500 Date: Sat, 16 Feb 2002 10:52:19 -0500 From: "Eric S. Raymond" To: Jeff Garzik Cc: linux-kernel@vger.kernel.org Subject: Possible breakthrough in the CML2 logjam? Message-ID: <20020216105219.A31001@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Jeff Garzik , linux-kernel@vger.kernel.org In-Reply-To: <200202151929.g1FJTaU03362@pc1-camc5-0-cust78.cam.cable.ntl.com> <20020215141433.B11369@thyrsus.com> <20020215195818.A3534@pc1-camc5-0-cust78.cam.cable.ntl.com> <20020215145421.A12540@thyrsus.com> <20020215213833.J27880@suse.de> <1013810923.807.1055.camel@phantasy> <20020215232832.N27880@suse.de> <3C6DE87C.FA96D1D6@mandrakesoft.com> <20020216095202.M23546@thyrsus.com> <3C6E7C75.A6659D72@mandrakesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3C6E7C75.A6659D72@mandrakesoft.com>; from jgarzik@mandrakesoft.com on Sat, Feb 16, 2002 at 10:36:21AM -0500 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jeff Garzik : > Ideally in the future I can add and update a driver's makefile and > configuration information by patching drivers/net/netdriver.c and > drivers/net/netdriver.conf, and touch absolutely no other files. That's very much the direction I'd like to go in, Jeff. I'm surprised and delighted to hear you say this. You're actually anticipating my plans for six months down the road. Maybe we have some common ground here. One of the objectives of the CML2 language design is to make it amenable to being generated by a metadata analyzer. I mean some very specific things by this. One important property which CML2 declarations have that CML1 syntax does not is that (a) they're not order-dependent, and (b) they have strong locality (that is, the syntactic context of a single declaration holds all the semantic information -- you don't have to go monkey-climbing up a bunch of enclosing syntax to parse it, or *generate* a bunch of enclosing syntax to express it). These properties tremendously simplify generating a rulebase from (so far hypothetical) analysis tools. My first step would be to automatically generate CML2 bus-guard information from annotations in the driver sources. Once I write a tool that can do that, I can whack about 25% of the rulebase, including most of the parts that are a maintainance headache. My longer-term plan is to whittle away at the manually-maintained rulebase until nothing but menu structure and a handful of cross- directory requirements are left. Everything else should be generated by a program that turns source-code metadata into stereotyped CML2 markup. Even a lot of the menu structure might be generatable, requiring it to be specified only in exception cases where as a matter of UI design choice you don't want to track the code hierarchy. This has been part of my long-term plan since about eighteen months ago. It's had a major, *major* impact on the language design. In particular it's one of the reasons visibility and implication can be declared separately from the menu structure. If you go back and look at the language design from this point of view, I think many things you might not have seen the point of before will become clearer. Note well two points: 1. This can't practicably be done in CML1. CML1 markup has crappy locality; the metadata analyzer would have to carry around way too much state about other symbols in order to generate the markup for any given one. 2. This design basically demands a single-apex tree. Otherwise I don't think you can get the consistency-checking right -- I haven't been able to invent a method to do it, anyway. So if you want this, please start backing CML2 and contributing in a positive way. I know how to get where you want to go. CML2 is specifically intentionally designed to make it possible, and I have the will to follow through. But for these good things to happen, CML2 *got to go in*. I cannot both continue the enormous effort of maintaining a parallel rulebase and move the ball forward towards automatic rule generation from metadata and other good things. That's what I want to be working on. -- Eric S. Raymond - 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/