Re: C++ in the kernel
- From: Julian Elischer <julian@xxxxxxxxxxxx>
- Date: Tue, 30 Oct 2007 10:38:13 -0700
Poul-Henning Kamp wrote:
In message <fg4bij$m42$1@xxxxxxxxxxxxx>, 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?
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- References:
- Re: C++ in the kernel
- From: Poul-Henning Kamp
- Re: C++ in the kernel
- Prev by Date: Re: C++ in the kernel
- Next by Date: Re: C++ in the kernel
- Previous by thread: Re: C++ in the kernel
- Next by thread: Re: C++ in the kernel
- Index(es):
Relevant Pages
|
|
