Re: Kernel frameworks

From: Diomidis Spinellis <dds_at_aueb.gr>
Date: Mon, 18 Oct 2004 23:17:11 +0300
Julian Elischer wrote:
[...]
> My gut feeling is that the same algorythms and data structure mechanisms
> 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 create
> 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–48, 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–76, 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ëller and P. Kafka, editors,
Proceedings ESREL '99 — The Tenth European Conference on Safety and
Reliability, pages 627–631, 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–99, February 2001.
http://www.spinellis.gr/pubs/jrnl/2000-JSS-DSLPatterns/html/dslpat.html

Diomidis - dds_at_
Received on Mon Oct 18 2004 - 18:17:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:18 UTC