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


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



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  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






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 30 2008



 next sibling parent reply 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






 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 30 2008



  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






 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 31 2008



prev sibling  parent  Walter Bright <newshound1 digitalmars.com>  writes:


I suggest starting a new thread with this, so people can see it!



 Jan 30 2008