From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 20:17:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2334016A4CE; Mon, 18 Oct 2004 20:17:24 +0000 (GMT) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id B662643D1D; Mon, 18 Oct 2004 20:17:22 +0000 (GMT) (envelope-from dds@aueb.gr) Received: from mx-av-02.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) i9IKHAG9008787; Mon, 18 Oct 2004 23:17:10 +0300 Received: from mx-as-01.forthnet.gr (mx-as.forthnet.gr [193.92.150.226]) i9IKHAar014267; Mon, 18 Oct 2004 23:17:10 +0300 Received: from forthnet.gr (athmta04.forthnet.gr [193.92.150.25]) i9IKH8wq007389; Mon, 18 Oct 2004 23:17:08 +0300 Received: from [192.168.136.17] (ppp17-adsl-153.ath.forthnet.gr [212.251.107.153]) by forthnet.gr (8.12.11/8.12.11) with ESMTP id i9IKH8Ur019502; Mon, 18 Oct 2004 23:17:08 +0300 Message-ID: <417424C7.3020602@aueb.gr> Date: Mon, 18 Oct 2004 23:17:11 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en, el, de MIME-Version: 1.0 To: Julian Elischer References: <4172E741.7080508@elischer.org> <4172EB01.9010202@elischer.org> In-Reply-To: <4172EB01.9010202@elischer.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Flag: NO cc: Robert Watson cc: current@freebsd.org Subject: Re: Kernel frameworks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 20:17:24 -0000 Julian Elischer wrote: [...] > My gut feeling is that the same algorythms and data structure mechanism= s > keep occuring again and again in teh kernel, and that it should be > possible to > specify the kernel in a meta-language (also known as a Very High Level > Language) > and generate the result. I've actually thought a little about this. > I havent seen a language that fits the bill yet. Does anyone have a > favourite > VHLL that they think could be used to describe a kernel? My suspicion > is that the descriptions would be such that we'd probably have to creat= e > our own KDS > (Kernel descripion Language :-) You are describing a domain-specific language (DSL). This is an ongoing, but currently less than hot, research topic. The Usenix Association sponsored two conferences on the subject in 1997 [1] and 1999 [2]. I've been playing with DSLs for more than 15 years [3-6]; reference [6] contains a (rather academic) survey of how DSLs are typically implemented and used. I've also used DSLs extensively in practice in the implementation of a medium-sized software project: a 300KLOC CAD system for civil engineers and architects. In that system 287KLOC are in C/C++; 16KLOC are in 12 different DSLs. I feel that DSLs offer significant benefits, especially when they are first used in the areas of a system where they are most applicable (think our kernel configuration file). Thereafter, the marginal returns quickly diminish, and the associated problems take over. In a summary, the most important problems are: - Finding or training developers to use the DSLs - Maintaining the DSL compilers - Development (e.g. debugger) tool support One current promissing approach is extensible languages, such as those made possible by the C# and the Java 5.0 code annotations. Personally, I believe that C++ is now a serious candidate for an OS implementation language. I know of the many less than successful object-oriented OS implementation attempts in the late 80s and early 90s, but I believe that those used a wrong approach (use object for everything) and an immature version of C++. Nowadays I would use the C++ in an OS implementation effort for its encapsulation and generic programming facilities, and would very sparingly employ inheritance and virtual methods. As you correctly point out, this is all day-dreaming, because of the ammount of legacy code we have on our hands. [1] Chris Ramming, editor. Proceedings of the Conference on Domain-Specific Languages October 15-17, 1997 Santa Barbara, California, USA. http://www.usenix.org/publications/library/proceedings/dsl97/ [2] Thomas Ball, editor. The 2nd Conference on Domain-Specific Languages. October 3-5, 1999. Austin, Texas, USA. http://www.usenix.org/publications/library/proceedings/dsl99/ [3] Diomidis Spinellis. Implementing Haskell: Language implementation as a tool building exercise. Structured Programming (Software Concepts and Tools), 14:37=9648, 1993. http://www.spinellis.gr/pubs/jrnl/1993-StrProg-Haskell/html/exp.html [4] Diomidis Spinellis and V. Guruprasad. Lightweight languages as software engineering tools. In J. Christopher Ramming, editor, USENIX Conference on Domain-Specific Languages, pages 67=9676, Berkeley, CA, October 1997. Usenix Association. http://www.spinellis.gr/pubs/conf/1997-DSL-Lightweight/html/paper.html [5] Diomidis Spinellis. Reliable software implementation using domain specific languages. In G. I. Schu=EBller and P. Kafka, editors, Proceedings ESREL '99 =97 The Tenth European Conference on Safety and Reliability, pages 627=96631, Rotterdam, September 1999. ESRA, VDI, TUM, A. A. Balkema. http://www.spinellis.gr/pubs/conf/1999-ESREL-SoftRel/html/dsl.html [6] Diomidis Spinellis. Notable design patterns for domain specific languages. Journal of Systems and Software, 56(1):91=9699, February 2001.= http://www.spinellis.gr/pubs/jrnl/2000-JSS-DSLPatterns/html/dslpat.html Diomidis - dds@