www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Experimental OS development using D

reply Harry Vennik <htvennik zonnet.nl> writes:
Hi,

At the beginning of this year I'd like to present a whole new idea that very
much involves the D
Programming Language. My idea is to start development of an experimental
operating system, that
should be constructed in an object-oriented way as much as possible, but no
'forcing of OOP at all
cost'. Of course OS implementation involves a lot of low-level coding. The one
and only suitable
language to combine low-level coding and OOP appears to be D. (Don't argue it
could be C++ too, that
language is unusable because of it's immense complexity. I keep asing myself
why so many people use
it anyway...)

The OS should consist of a microkernel similar to L4, to be written in C (as
much as possible) and
Assembly (where necessary). And any number of services running on top of it,
all to be written in D. It
should be an OS that is inspired on UNIX, but not be a real UNIX
implementation. Rather it should feel
like an evolution of the UNIX-way of doing things.

I realize that the current performance of D might not be suitable for serious
OS development, but I do
not think of that as a real problem. I think that in the very first, highly
experimental phase of
development, the actual performance is not much of an issue. Later on, when it
will become an issue,
the D compiler will probably have been improved already to provide that
optimization performance.

I chose the D Programming Language only for its bare language features, not
anything else. It was
simply the only language I could find that met my requirements. Any libraries
or frameworks won't help
in OS development anyway, because they are supposed to be used on top of an OS.
Of course the
interfaces of the OS should be optimized to make it as easy as possible to use
it using the D standard
library (be it Phobos, or Tango, or whatever will turn out to become some sort
of standard). Also the
development of the OS might influence the development of a D standard library
at some points.

Is there anyone here who is interested in working with me to get that project
going, and help by
contributing in the development of a specification and/or in implementation of
those (including PoC
coding)?

Regards,

Harry Vennik
Jan 02 2007
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Harry Vennik wrote:
 
 The OS should consist of a microkernel similar to L4, to be written in C
 (as much as possible) and Assembly (where necessary). And any number of
 services running on top of it, all to be written in D. It should be an OS
 that is inspired on UNIX, but not be a real UNIX implementation. Rather it
 should feel like an evolution of the UNIX-way of doing things.

Why would you want to write the kernel itself in C? AFAIK, there is no real problem in coding the kernel itself in D too. I'm not going to volunteer on this project, but I wish you good luck. Source distributions would be so much more interesting with a language as quickly compiled as D. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jan 02 2007
prev sibling next sibling parent reply Alexander Panek <a.panek brainsware.org> writes:
Harry Vennik wrote:
 Hi,
 
 At the beginning of this year I'd like to present a whole new idea that very
much involves the D
 Programming Language. My idea is to start development of an experimental
operating system, that
 should be constructed in an object-oriented way as much as possible, but no
'forcing of OOP at all
 cost'. Of course OS implementation involves a lot of low-level coding. The one
and only suitable
 language to combine low-level coding and OOP appears to be D. (Don't argue it
could be C++ too, that
 language is unusable because of it's immense complexity. I keep asing myself
why so many people use
 it anyway...)
 
 The OS should consist of a microkernel similar to L4, to be written in C (as
much as possible) and
 Assembly (where necessary). And any number of services running on top of it,
all to be written in D. It
 should be an OS that is inspired on UNIX, but not be a real UNIX
implementation. Rather it should feel
 like an evolution of the UNIX-way of doing things.
 
 I realize that the current performance of D might not be suitable for serious
OS development, but I do
 not think of that as a real problem. I think that in the very first, highly
experimental phase of
 development, the actual performance is not much of an issue. Later on, when it
will become an issue,
 the D compiler will probably have been improved already to provide that
optimization performance.
 
 I chose the D Programming Language only for its bare language features, not
anything else. It was
 simply the only language I could find that met my requirements. Any libraries
or frameworks won't help
 in OS development anyway, because they are supposed to be used on top of an
OS. Of course the
 interfaces of the OS should be optimized to make it as easy as possible to use
it using the D standard
 library (be it Phobos, or Tango, or whatever will turn out to become some sort
of standard). Also the
 development of the OS might influence the development of a D standard library
at some points.
 
 Is there anyone here who is interested in working with me to get that project
going, and help by
 contributing in the development of a specification and/or in implementation of
those (including PoC
 coding)?
 
 Regards,
 
 Harry Vennik

Hello Harry, I'm doing a research project with pretty similar approaches, with just one difference: the kernel shall be totally in D and necessary parts in assembly (may it be inline assembly, or nasm/yasm/gas/whatever - just the right tool for each individual job). I have a very little code base already in a public Subversion repository, if you want to take a look. The base idea of this project was meant to be implemented in C, but I'm trying to push through a D version for the proof of the statement, that D is a system programming language - and it is, a great one even! Unfortunately there's not too much information or documentation yet, as it's just a hobby project I'm doing with a friend of mine in our spare time (got too little of that lately :( ). Anyways, here's the URL of the C code base we have so far implemented and running: http://trac.brainsware.org/ocb The D version is just some testing code, a sketch if you want. I'm working on a better implementation of the basic things at the moment. Apart from that, I haven't got interrupts or exceptions to work yet - still some research to do there. http://trac.brainsware.org/ocd/ Great to see that I'm not the only one (together with the Titan folks, of course ;) ) who thinks that D would be the perfect language for OS development! :) Best regards, Alex P.S.: What do you mean with "PoC coding"? Proof of Concept?
Jan 02 2007
parent reply Harry Vennik <htvennik zonnet.nl> writes:
Hi,

Thanks for the quick replies.

In general, most mentioned already is the question 'why C instead of D for the
microkernel?'. The
answer is that there is no OOP involved in the microkernel at all, and the
added value of D would
probably be nothing there. If any advantages of using D also for the
microkernel become obvious, I'll
likely change my mind, and indeed implement it in D too. Anyway, keep in mind:
a micro kernel should
really be micro! It would only implement page level memory management, a
scheduler and an IPC
meganism. The rest is up to the services.

 Alex: Very nice to hear there are more people with approximately the same
idea. I haven't really
looked at your source yet, but I will soon. And yes, you got it right: PoC is
short for 'Proof of Concept'.

 Lars: What do you mean to say by 'Source distributions would be so much more
interesting with a
language as quickly compiled as D.'?

 Bjoern: Yes, I read the announcement of Tango just before I composed my
initial post. Haven't really
looked what the lib is like yet, but I will. POSIX is probaly not much of
interest, because it is a C
interface, and thus not OO. However, something like a POSIX compatibility
library programmed on top
of the OO system may be done some day to make it possible to compile existing
apps for the new OS. (I
know that is a real change of roles. With current OSs you'd rather code an
OO-style framework on top
of POSIX.)

Regards,

Harry
Jan 02 2007
next sibling parent reply BCS <BCS pathlink.com> writes:
Harry Vennik wrote:
 Hi,
 
 Thanks for the quick replies.
 
 Anyway, keep in mind: a micro kernel should
 really be micro! It would only implement page level memory management, a
scheduler and an IPC
 meganism. The rest is up to the services.


What about I/O? mmap the file from a service for block devices? shared memory for the buffer for stream? I have thought this would be an interesting way to go.
 Regards,
 
 Harry

Jan 02 2007
parent reply Harry Vennik <htvennik zonnet.nl> writes:
 What about I/O? mmap the file from a service for block devices? shared
 memory for the buffer for stream? I have thought this would be an
 interesting way to go.

Indeed, might be something like the shared memory buffer. Such would allow very good performance. There may be some process isolation problems / security risks. But I think those will be solvable.
Jan 02 2007
parent reply BCS <nothing pathlink.com> writes:
Harry Vennik wrote:
 What about I/O? mmap the file from a service for block devices? shared
 memory for the buffer for stream? I have thought this would be an
 interesting way to go.

Indeed, might be something like the shared memory buffer. Such would allow very good performance. There may be some process isolation problems / security risks. But I think those will be solvable.

Put the security in stetting up the shared buffers and that should do it I'd think. Read access lets you map it in in a read only page, read/write... etc. One thought I had on this issue is that it allows much of the IO to run without system calls/context switches if the stream access and whatnot is all run as part of the standard system lib. Plus, while you can mess with your stream meta data, it only hoses you.
Jan 02 2007
parent reply Harry Vennik <htvennik zonnet.nl> writes:
BCS wrote:
 Put the security in stetting up the shared buffers and that should do
 it I'd think.
 Read access lets you map it in in a read only page, read/write... etc.

 One thought I had on this issue is that it allows much of the IO to
 run without system calls/context switches if the stream access and
 whatnot is all run as part of the standard system lib. Plus, while you
 can mess with your stream meta data, it only hoses you.

I have been thinking that way too, but it is difficult to see how much it really prevents context switches. It may just obscure them by having them occur only in response to certain events (which may occur regularly), instead of having the predictable context switch for every read/write/whatever you do. Memory-mapping the file will prevent this, but is costly for bigger files, so this needs some thought. Anyway, if a way is found to have a reliable shared-buffer implementation that will not compensate its lower number of context switches by having more of another unwanted side-effect (e.g. excessive memory usage), than that would certainly be the way to go. Harry
Jan 04 2007
parent reply BCS <BCS pathlink.com> writes:
Harry Vennik wrote:
 BCS wrote:
 
Put the security in stetting up the shared buffers and that should do
it I'd think.
Read access lets you map it in in a read only page, read/write... etc.

One thought I had on this issue is that it allows much of the IO to
run without system calls/context switches if the stream access and
whatnot is all run as part of the standard system lib. Plus, while you
can mess with your stream meta data, it only hoses you.

I have been thinking that way too, but it is difficult to see how much it really prevents context switches. It may just obscure them by having them occur only in response to certain events (which may occur regularly), instead of having the predictable context switch for every read/write/whatever you do. Memory-mapping the file will prevent this, but is costly for bigger files, so this needs some thought. Anyway, if a way is found to have a reliable shared-buffer implementation that will not compensate its lower number of context switches by having more of another unwanted side-effect (e.g. excessive memory usage), than that would certainly be the way to go. Harry

The appropriate snide response here is "memory is cheap". But I've never bought into that one. If the IO system allowed arbitrary mapping of memory pages to disk blocks: sysCallMapPage2Block(int fd, size_t block, void* page, uint count = 1); this might not be fairly fast as far as the OS side goes. if(fd.good && fd.size >= block && user.pageCount + count < suer.pageLimit) MapPage(); The other side would be totally up to the stdlib ("not your problem" :-) This would have some other cool effects like use this under malloc (fd == -1 indicates blank pages)
Jan 04 2007
parent reply Harry Vennik <htvennik zonnet.nl> writes:
Harry Vennik wrote:
 BCS wrote:

Put the security in stetting up the shared buffers and that should do
it I'd think.
Read access lets you map it in in a read only page, read/write... etc.

One thought I had on this issue is that it allows much of the IO to
run without system calls/context switches if the stream access and
whatnot is all run as part of the standard system lib. Plus, while you
can mess with your stream meta data, it only hoses you.

I have been thinking that way too, but it is difficult to see how much it really prevents context switches. It may just obscure them by having them occur only in response to certain events (which may occur regularly), instead of having the predictable context switch for every read/write/whatever you do. Memory-mapping the file will prevent this, but is costly for bigger files, so this needs some thought. Anyway, if a way is found to have a reliable shared-buffer implementation that will not compensate its lower number of context switches by having more of another unwanted side-effect (e.g. excessive memory usage), than that would certainly be the way to go. Harry

The appropriate snide response here is "memory is cheap". But I've never bought into that one. If the IO system allowed arbitrary mapping of memory pages to disk blocks: sysCallMapPage2Block(int fd, size_t block, void* page, uint count = 1); this might not be fairly fast as far as the OS side goes. if(fd.good && fd.size >= block && user.pageCount + count < suer.pageLimit) MapPage(); The other side would be totally up to the stdlib ("not your problem" :-) This would have some other cool effects like use this under malloc (fd == -1 indicates blank pages)

No, this won't fit in the concept. I think of it like this (Only mentioning the relevant steps.): - A process does an IPC call to the filesystem service to map some data from a file into memory. - The fs service reads the data from disk and puts it into newly allocated memory page(s). - The fs service announces to the kernel which pages should be mapped into the virtual address space of the calling process, and returns the pointer. - The kernel maps the shareable memory into the virtual address space of the calling process, and translates the returned pointer to reflect the correct address in the calling process' address space. I think that's the best we can do. It is secure (at least at first sight), and it should save quite a lot of syscalls, except when reading/writing a large file randomly. Harry
Jan 04 2007
parent BCS <nothing pathlink.com> writes:
Harry Vennik wrote:
 
 No, this won't fit in the concept. I think of it like this (Only mentioning
the relevant steps.):
 - A process does an IPC call to the filesystem service to map some data from a
file into memory.
 - The fs service reads the data from disk and puts it into newly allocated
memory page(s).
 - The fs service announces to the kernel which pages should be mapped into the
virtual address space
 of the calling process, and returns the pointer.
 - The kernel maps the shareable memory into the virtual address space of the
calling process, and
 translates the returned pointer to reflect the correct address in the calling
process' address space.
 
 I think that's the best we can do. It is secure (at least at first sight), and
it should save quite a lot of
 syscalls, except when reading/writing a large file randomly.
 
 Harry

This is quite a bit different from what I was thinking of. I'll have to think on it. Could it handle the "lazy-load" type of mmap? The kind where nothing is loaded when you map in the file, instead that all waits for page faults using the same device as the virtual memory system. Maybe the file system process could just do a memory page to disk block mapping for the other process.
Jan 04 2007
prev sibling next sibling parent Alexander Panek <a.panek brainsware.org> writes:
Harry Vennik wrote:
 Hi,
 
 Thanks for the quick replies.
 
 In general, most mentioned already is the question 'why C instead of D for the
microkernel?'. The
 answer is that there is no OOP involved in the microkernel at all, and the
added value of D would
 probably be nothing there. If any advantages of using D also for the
microkernel become obvious, I'll
 likely change my mind, and indeed implement it in D too. Anyway, keep in mind:
a micro kernel should
 really be micro! It would only implement page level memory management, a
scheduler and an IPC
 meganism. The rest is up to the services.

Oh, trust me. OO does a good job here, too. Actually, if you take a look at OCB, it's already doing it in an object oriented way, as far as possible in C.
 
  Alex: Very nice to hear there are more people with approximately the same
idea. I haven't really
 looked at your source yet, but I will soon. And yes, you got it right: PoC is
short for 'Proof of Concept'.
 

Great. Wanted to mention that phrase too, but didn't quite get a good sounding sentence formulated.. X-P
 Regards,
 
 Harry

Best regards, Alex
Jan 02 2007
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Harry Vennik wrote:
 
  Lars: What do you mean to say by 'Source distributions would be so much
 more interesting with a language as quickly compiled as D.'?

With source distributions, I mean Linux distributions like Gentoo, and others, where part of the installation process is to compile everything using flags to make an OS that fits your computer very well. What put me off using Gentoo, was mostly that it took at least a couple of days to set up a system with a full desktop. D is so much faster to compile, that the installation likely would become much more endurable. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jan 02 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Harry Vennik wrote:
 In general, most mentioned already is the question 'why C instead of D for the
microkernel?'. The
 answer is that there is no OOP involved in the microkernel at all, and the
added value of D would
 probably be nothing there.

I'd turn the question around and ask what advantage there is to writing in C?
Jan 02 2007
parent Harry Vennik <htvennik zonnet.nl> writes:
Walter Bright wrote:
 Harry Vennik wrote:
 In general, most mentioned already is the question 'why C instead of D for the
microkernel?'. The
 answer is that there is no OOP involved in the microkernel at all, and the
added value of D would
 probably be nothing there.

I'd turn the question around and ask what advantage there is to writing in C?

Hmmm, You are undoubtedly asking a very legitimate question. And I don't know the answer now, but I am not yet sure there really won't be a good reason in the end. If there appears to be none, it will be D to keep things consistent. Harry
Jan 04 2007
prev sibling next sibling parent "bls" <killing__Zoe web.de> writes:
Hi Harry,
Why C and ASM.
Have a look at TANGO ( New library announcement) you may find some very
interesting infos. POSIX just to name something.
Good luck Bjoern

"Harry Vennik" <htvennik zonnet.nl> schreef in bericht
news:endnt7$fe7$1 digitaldaemon.com...
 Hi,

 At the beginning of this year I'd like to present a whole new idea that

 Programming Language. My idea is to start development of an experimental

 should be constructed in an object-oriented way as much as possible, but

 cost'. Of course OS implementation involves a lot of low-level coding. The

 language to combine low-level coding and OOP appears to be D. (Don't argue

 language is unusable because of it's immense complexity. I keep asing

 it anyway...)

 The OS should consist of a microkernel similar to L4, to be written in C

 Assembly (where necessary). And any number of services running on top of

 should be an OS that is inspired on UNIX, but not be a real UNIX

 like an evolution of the UNIX-way of doing things.

 I realize that the current performance of D might not be suitable for

 not think of that as a real problem. I think that in the very first,

 development, the actual performance is not much of an issue. Later on,

 the D compiler will probably have been improved already to provide that

 I chose the D Programming Language only for its bare language features,

 simply the only language I could find that met my requirements. Any

 in OS development anyway, because they are supposed to be used on top of

 interfaces of the OS should be optimized to make it as easy as possible to

 library (be it Phobos, or Tango, or whatever will turn out to become some

 development of the OS might influence the development of a D standard

 Is there anyone here who is interested in working with me to get that

 contributing in the development of a specification and/or in

 coding)?

 Regards,

 Harry Vennik

Jan 02 2007
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Harry Vennik wrote:
 Is there anyone here who is interested in working with me to get that project
going, and help by
 contributing in the development of a specification and/or in implementation of
those (including PoC
 coding)?

Just in case nobody has mentioned it: a small and elegant UNIX kernel to use as a source of inspiration is Minix 3 (http://www.minix3.org/). I've seen Tanenbaum talking about it, and Minix 3 is a fresh new approach to OS design featuring high modularity: the kernel itself boasts only 4000 lines of code. It would be interesting to see how that translates in D. Andrei
Jan 04 2007
next sibling parent kris <fu bar.org> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Harry Vennik wrote:
 
 Is there anyone here who is interested in working with me to get that 
 project going, and help by
 contributing in the development of a specification and/or in 
 implementation of those (including PoC
 coding)?

Just in case nobody has mentioned it: a small and elegant UNIX kernel to use as a source of inspiration is Minix 3 (http://www.minix3.org/). I've seen Tanenbaum talking about it, and Minix 3 is a fresh new approach to OS design featuring high modularity: the kernel itself boasts only 4000 lines of code. It would be interesting to see how that translates in D. Andrei

That looks really interesting ... thanks for the link
Jan 04 2007
prev sibling next sibling parent reply John Reimer <terminal.node gmail.com> writes:
On Thu, 04 Jan 2007 17:36:26 -0800, Andrei Alexandrescu (See Website For
Email) wrote:

 Harry Vennik wrote:
 Is there anyone here who is interested in working with me to get that project
going, and help by
 contributing in the development of a specification and/or in implementation of
those (including PoC
 coding)?

Just in case nobody has mentioned it: a small and elegant UNIX kernel to use as a source of inspiration is Minix 3 (http://www.minix3.org/). I've seen Tanenbaum talking about it, and Minix 3 is a fresh new approach to OS design featuring high modularity: the kernel itself boasts only 4000 lines of code. It would be interesting to see how that translates in D. Andrei

Very interesting! I'll download the svn source and check it out. :) -JJR
Jan 04 2007
parent reply Harry Vennik <htvennik zonnet.nl> writes:
Hi all,

I announced this project just a little more than one year ago, but then I had
to stop it right away because
of some personal problems. Recently I picked it up again, but to really gain
any progress, I really need
help from one or more real D gurus, as there is one very essential problem I
cannot solve myself.

I'd like to build my OS on top of the OKL4 microkernel from Open Kernel Labs.
That microkernel is
written in C and C++, but in my OS, everything running on top of it should be
in D. (Although it might
be that I use some existing servers at first, and replace them by
D-implementations later.)

Now I'd like to have automated code generation for IPC, without using IDL. I.e.
i want to be able to
simply code a D interface and then have some way to expose that interface to be
called through IPC,
without the need to write the actual IPC code over and over again for each
interface. Ideally the IPC code
would be compatible to code generated from IDL through magpie, as such would
allow D-clients to call
C-servers and vice versa, this is not a requirement however.

Currently I feel like this is the most difficult part to code of the whole OS
(maybe just because I do have
quite some knowledge about OSes, but almost nothing about compilers and code
generation...)

Anyone interested to help me to get this done?

Regards,

Harry

== Quote from John Reimer (terminal.node gmail.com)'s article
 On Thu, 04 Jan 2007 17:36:26 -0800, Andrei Alexandrescu (See Website For
 Email) wrote:
 Harry Vennik wrote:
 Is there anyone here who is interested in working with me to get that project
going, and help by
 contributing in the development of a specification and/or in implementation of
those (including



 coding)?

Just in case nobody has mentioned it: a small and elegant UNIX kernel to use as a source of inspiration is Minix 3 (http://www.minix3.org/). I've seen Tanenbaum talking about it, and Minix 3 is a fresh new approach to OS design featuring high modularity: the kernel itself boasts only 4000 lines of code. It would be interesting to see how that translates in D. Andrei

I'll download the svn source and check it out. :) -JJR

Jan 30 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
I suggest starting a new thread with this, so people can see it!
Jan 30 2008
prev sibling parent Harry Vennik <htvennik zonnet.nl> writes:
Graham St Jack Wrote:

 On Wed, 30 Jan 2008 19:37:09 +0000, Harry Vennik wrote:
 
 Hi all,
 
 I announced this project just a little more than one year ago, but then
 I had to stop it right away because of some personal problems. Recently
 I picked it up again, but to really gain any progress, I really need
 help from one or more real D gurus, as there is one very essential
 problem I cannot solve myself.

You might want to take a look at this other project that sounds very similar: http://www.slate-project.org/start

It has some similarity indeed, but a very big difference is that they plan to use the Linux kernel, which is a monolithic kernel. As mentioned, OKL4 is a microkernel. At the higher level I might be able to co-operate with Slate if other design decisions are less far apart.
 
 I'd like to build my OS on top of the OKL4 microkernel from Open Kernel
 Labs. That microkernel is written in C and C++, but in my OS, everything
 running on top of it should be in D. (Although it might be that I use
 some existing servers at first, and replace them by D-implementations
 later.)
 
 Now I'd like to have automated code generation for IPC, without using
 IDL. I.e. i want to be able to simply code a D interface and then have
 some way to expose that interface to be called through IPC, without the
 need to write the actual IPC code over and over again for each
 interface. Ideally the IPC code would be compatible to code generated
 from IDL through magpie, as such would allow D-clients to call C-servers
 and vice versa, this is not a requirement however.
 
 Currently I feel like this is the most difficult part to code of the
 whole OS (maybe just because I do have quite some knowledge about OSes,
 but almost nothing about compilers and code generation...)
 
 Anyone interested to help me to get this done?
 
 Regards,
 
 Harry
 
 == Quote from John Reimer (terminal.node gmail.com)'s article
 On Thu, 04 Jan 2007 17:36:26 -0800, Andrei Alexandrescu (See Website
 For Email) wrote:
 Harry Vennik wrote:
 Is there anyone here who is interested in working with me to get
 that project going, and help by contributing in the development of a
 specification and/or in implementation of those (including



 coding)?

Just in case nobody has mentioned it: a small and elegant UNIX kernel to use as a source of inspiration is Minix 3 (http://www.minix3.org/). I've seen Tanenbaum talking about it, and Minix 3 is a fresh new approach to OS design featuring high modularity: the kernel itself boasts only 4000 lines of code. It would be interesting to see how that translates in D. Andrei

I'll download the svn source and check it out. :) -JJR



Jan 31 2008
prev sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Wed, 30 Jan 2008 19:37:09 +0000, Harry Vennik wrote:

 Hi all,
 
 I announced this project just a little more than one year ago, but then
 I had to stop it right away because of some personal problems. Recently
 I picked it up again, but to really gain any progress, I really need
 help from one or more real D gurus, as there is one very essential
 problem I cannot solve myself.

You might want to take a look at this other project that sounds very similar: http://www.slate-project.org/start
 
 I'd like to build my OS on top of the OKL4 microkernel from Open Kernel
 Labs. That microkernel is written in C and C++, but in my OS, everything
 running on top of it should be in D. (Although it might be that I use
 some existing servers at first, and replace them by D-implementations
 later.)
 
 Now I'd like to have automated code generation for IPC, without using
 IDL. I.e. i want to be able to simply code a D interface and then have
 some way to expose that interface to be called through IPC, without the
 need to write the actual IPC code over and over again for each
 interface. Ideally the IPC code would be compatible to code generated
 from IDL through magpie, as such would allow D-clients to call C-servers
 and vice versa, this is not a requirement however.
 
 Currently I feel like this is the most difficult part to code of the
 whole OS (maybe just because I do have quite some knowledge about OSes,
 but almost nothing about compilers and code generation...)
 
 Anyone interested to help me to get this done?
 
 Regards,
 
 Harry
 
 == Quote from John Reimer (terminal.node gmail.com)'s article
 On Thu, 04 Jan 2007 17:36:26 -0800, Andrei Alexandrescu (See Website
 For Email) wrote:
 Harry Vennik wrote:
 Is there anyone here who is interested in working with me to get
 that project going, and help by contributing in the development of a
 specification and/or in implementation of those (including



 coding)?

Just in case nobody has mentioned it: a small and elegant UNIX kernel to use as a source of inspiration is Minix 3 (http://www.minix3.org/). I've seen Tanenbaum talking about it, and Minix 3 is a fresh new approach to OS design featuring high modularity: the kernel itself boasts only 4000 lines of code. It would be interesting to see how that translates in D. Andrei

I'll download the svn source and check it out. :) -JJR


Jan 30 2008