C++ in the kernel

[Julian Elischer]

Poul-Henning Kamp wrote:
> In message <fg4bij$m42$1 at ger.gmane.org>, Ivan Voras writes:

> 
> For instance, the entire "dual-address space" dictomy og system
> calls/copy{in,out} and the very concept of interrupts are very
> tricky to sensibly express in anything but C.
> 
> So what I've been tinkering with, is not a new language, but a
> C dialect enhanced to make kernel programming simpler.


I've also been doing some mental tinkering with the idea of a language 
specifically designed for the kernel.

"But that was what C was designed for" I hear you say.
Yes, but that was 30 years ago (hmmm actually 35 or so since C 
was introduced I think). 
There are a lot of things we do in the kernel that could do with abstracting.
Really if you look at it, there are some special addressing requirements
such as those phk points to.. knowledge of physical space, kernel space and 
the user space abstraction. 
There are also lots of locking requirements that might be hidden, and 
the ability to cope with kernel modules might be something that we may 
be able to build in. 

I sometimes wonder if there isn't a room for 
a language where you can specify more what you want out of it than 
how to do it. Most of the kernel is composed of about 30 different
CS101 algorithms.

hash tables
linked lists
chained buffers
a couple of locking primatives
event handlers
method tables
'items' linked in to multiple lists (e.g. LRU+hash etc)
etc.

if you could abstract out most of these you might be able 
to specify the behaviour you want and let the language take care of the details..

for (a random, trivial) example, threads are linked off processes.
they are cached.
they have a stack associated with them.
There is hand written code to take care of this but given the following 
specification, all that could be automated.

0/ there is a 1 to many direct correlation between "processes" (defined elsewhere)
and threads
1/ threads are iteratable from the process.
2/ a thread can find its process easily.
3/ threads can be added or removed from a process
4/ threads can sometimes need to be locked from changes 
5/ a thread is associated with a context (by which I mean there is a context
 from which a thread structure is 'special'. i.e. curthread points to it.
6/ threads need to be allocated and freed. 
7/ allocation time can be critical.


given the above, any of us could possibly write the linkage code blindfolded.
So, why should we write it at all?