www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Operating System in D

reply Trevor Parscal <Trevor_member pathlink.com> writes:
An Operating System In D...

I have extreme ambition, tons of ideas, programming skills, and enough time to
make a consistent effort. Perhaps I could get some help from some of you guys,
and get a proof of concept together... Like pragma said... And yes, I have seen,
and played with the beginings of a kernel in D that are posted on that wiki, and
they should help us to get something together as well.

Idea...
A kernel
- execute several different kinds of compiled code (DDL seems to help here)
- has garbage collection (D's GC should work)
- perhaps an exokernel design (http://pdos.csail.mit.edu/exo.html)

Name...
Honestly, as long as it's not an achronym, I am all for it... So, name ideas
anyone?

Thanks,
Trevor Parscal
Oct 11 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <dih930$28uc$1 digitaldaemon.com>, Trevor Parscal says...
An Operating System In D...

I have extreme ambition, tons of ideas, programming skills, and enough time to
make a consistent effort. Perhaps I could get some help from some of you guys,
and get a proof of concept together... Like pragma said... And yes, I have seen,
and played with the beginings of a kernel in D that are posted on that wiki, and
they should help us to get something together as well.

Idea...
A kernel
- execute several different kinds of compiled code (DDL seems to help here)
- has garbage collection (D's GC should work)
- perhaps an exokernel design (http://pdos.csail.mit.edu/exo.html)
I'm new to exokernels, thanks for the link. It reminds me a lot of proper OO abstraction really, and makes sense: it gets you away from trying to be "everything to everyone" approach that seems to be the key problem with big OS designs (linux suffers here as much as windows). So I guess you could draft a root kernel easily (as it's understood to be *very* rudimentary and low-level) and build from there. So I guess the root kernel is where the GC lives? Works for me.
Name...
Honestly, as long as it's not an achronym, I am all for it... So, name ideas
anyone?
I'm not sold on any particular name yet, so here's a pile of suggestions instead. ;) If you want to extend the current greco/roman/planetary theme we have with D thus far, I would nominate the following: Janus - god of doorways, beginnings and endings Titan - the titans were the first among gods Atlas - 'sentenced' to bear the weight of the world on his shoulders Athena - godess of war and so the female counterpart to Ares/Mars (only with a more scrupulous reputation) . or anything else that fits. I know Kris has something going with names of tropical fruit/trees, with his "Mango" library. I've already decided that DSP's testbed server is going to be called "Sumac", after I went looking for other trees that had a taxonomical relationship to Mangos. Listing of Tropical Fruit - http://www.proscitech.com.au/trop/link.htm If I can think of anything more inspired, I'll post it to this thread. - EricAnderton at yahoo
Oct 11 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <dihb76$2amh$1 digitaldaemon.com>, pragma says...
I've already decided that DSP's testbed server is going to be
called "Sumac", after I went looking for other trees that had a taxonomical
relationship to Mangos.
Sumac: get the itch! Sumac, it really grows on you! (insert catchy slogan here) Sean
Oct 11 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <dihcan$2bsn$1 digitaldaemon.com>, Sean Kelly says...
In article <dihb76$2amh$1 digitaldaemon.com>, pragma says...
I've already decided that DSP's testbed server is going to be
called "Sumac", after I went looking for other trees that had a taxonomical
relationship to Mangos.
Sumac: get the itch! Sumac, it really grows on you! (insert catchy slogan here)
Nice. I might just use one of those. I might just use a 'fortune' style slogan field on the webpage, so I can use both. ;) A little while back I drafted a concept for a util that compiles XML data straight to D structures, as to eliminate the need for parsing XML at runtime. At first I called it "XML Configurator" which was quickly shortened to "XCON"... down the page, I scribbled the following slogans: - Freedom from markup lockup. - Break out of the XML stockade. - Is your application getting shived on performance? - Is your software doing 15 to life? - Because XML Parsers don't get time off for good behavior. - Rehabilitate your data. (I blame being stuck in a hotel room for a solid week, on business, with nothing to do but watch but the History Channel... I think it was "prison week" or something like that) - EricAnderton at yahoo
Oct 11 2005
parent Trevor Parscal <Trevor_member pathlink.com> writes:
In article <dihi6h$43d$1 digitaldaemon.com>, pragma says...
In article <dihcan$2bsn$1 digitaldaemon.com>, Sean Kelly says...
In article <dihb76$2amh$1 digitaldaemon.com>, pragma says...
I've already decided that DSP's testbed server is going to be
called "Sumac", after I went looking for other trees that had a taxonomical
relationship to Mangos.
Sumac: get the itch! Sumac, it really grows on you! (insert catchy slogan here)
Nice. I might just use one of those. I might just use a 'fortune' style slogan field on the webpage, so I can use both. ;) A little while back I drafted a concept for a util that compiles XML data straight to D structures, as to eliminate the need for parsing XML at runtime. At first I called it "XML Configurator" which was quickly shortened to "XCON"... down the page, I scribbled the following slogans: - Freedom from markup lockup. - Break out of the XML stockade. - Is your application getting shived on performance? - Is your software doing 15 to life? - Because XML Parsers don't get time off for good behavior. - Rehabilitate your data. (I blame being stuck in a hotel room for a solid week, on business, with nothing to do but watch but the History Channel... I think it was "prison week" or something like that) - EricAnderton at yahoo
You know, I wrote an XML parser designed to do just that, and than it turned into a really basic XML parser that I use an out of the box object in all my apps.. As it turns out, my parser was really fast, so, it defeated the purpose... :) If you ever want to see it, take a look at http://svn.dsource.org/projects/terra/trunk/terra/Source/Terra/Primitives/Structure.d Thanks, Trevor Parscal
Oct 11 2005
prev sibling next sibling parent Trevor Parscal <Trevor_member pathlink.com> writes:
If you want to extend the current greco/roman/planetary theme we have with D
thus far, I would nominate the following:

Janus - god of doorways, beginnings and endings
Titan - the titans were the first among gods  
Atlas - 'sentenced' to bear the weight of the world on his shoulders
Athena - godess of war and so the female counterpart to Ares/Mars (only with a
more scrupulous reputation)

. or anything else that fits.
Wow, so oddly, the original name for my OS I wanted to make long ago, and since, was Apollo.... I have even tried to do this D kernel under that name before... So, now I feel like thats a good idea... Thanks, Trevor Parscal
Oct 11 2005
prev sibling parent reply Niko Korhonen <niktheblak hotmail.com> writes:
pragma wrote:
 Janus - god of doorways, beginnings and endings
That's slightly too Javaish because it starts with a J. For some reason the Java people have a strong compulsion to name all their software J-something. I don't know if it's a part of Sun's Java EULA or something ('§8.7 The party hereby referred to as You must name all digital intellectual property hereby referred to as Software You create with the digital intellectual property copyrighted by Sun Microsystems hereby referred to as Java Software J-Something').
 Athena - godess of war and so the female counterpart to Ares/Mars (only with a
 more scrupulous reputation)
Now that would be insanely cool! With a nice reference to Digital Mars too :) -- Niko Korhonen SW Developer
Oct 11 2005
parent Trevor Parscal <Trevor_member pathlink.com> writes:
In article <dii9pm$l85$1 digitaldaemon.com>, Niko Korhonen says...
pragma wrote:
 Janus - god of doorways, beginnings and endings
That's slightly too Javaish because it starts with a J. For some reason the Java people have a strong compulsion to name all their software J-something. I don't know if it's a part of Sun's Java EULA or something ('§8.7 The party hereby referred to as You must name all digital intellectual property hereby referred to as Software You create with the digital intellectual property copyrighted by Sun Microsystems hereby referred to as Java Software J-Something').
 Athena - godess of war and so the female counterpart to Ares/Mars (only with a
 more scrupulous reputation)
Now that would be insanely cool! With a nice reference to Digital Mars too :) -- Niko Korhonen SW Developer
Yes, but.. AthenaOS is already taken.. :) http://savannah.nongnu.org/projects/athena/ Thanks, Trevor Parscal
Oct 12 2005
prev sibling next sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message 
news:dih930$28uc$1 digitaldaemon.com...
 An Operating System In D...
I would be willing to lend whatever assistance I can, though I'm no OS expert.
 - execute several different kinds of compiled code (DDL seems to help 
 here)
 - has garbage collection (D's GC should work)
 - perhaps an exokernel design (http://pdos.csail.mit.edu/exo.html)

 Name...
 Honestly, as long as it's not an achronym, I am all for it... So, name 
 ideas
 anyone?

 Thanks,
 Trevor Parscal 
Oct 11 2005
prev sibling next sibling parent reply Carotinho <carotinobg yahoo.it> writes:
Trevor Parscal wrote:

 An Operating System In D...
 
 I have extreme ambition, tons of ideas, programming skills, and enough
 time to make a consistent effort. Perhaps I could get some help from some
 of you guys, and get a proof of concept together... Like pragma said...
 And yes, I have seen, and played with the beginings of a kernel in D that
 are posted on that wiki, and they should help us to get something together
 as well.
 
 Idea...
 A kernel
 - execute several different kinds of compiled code (DDL seems to help
 here) - has garbage collection (D's GC should work)
 - perhaps an exokernel design (http://pdos.csail.mit.edu/exo.html)
 
 Name...
 Honestly, as long as it's not an achronym, I am all for it... So, name
 ideas anyone?
I'd put the garbage collector in the kernel, and if you want some memory, you have to ask him the permission! So there is one big gc for everyone. No ideas about shared libs etc. though... Carotinho
Oct 11 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
In article <dihjg2$4pc$1 digitaldaemon.com>, Carotinho says...
Trevor Parscal wrote:

 An Operating System In D...
 
 I have extreme ambition, tons of ideas, programming skills, and enough
 time to make a consistent effort. Perhaps I could get some help from some
 of you guys, and get a proof of concept together... Like pragma said...
 And yes, I have seen, and played with the beginings of a kernel in D that
 are posted on that wiki, and they should help us to get something together
 as well.
 
 Idea...
 A kernel
 - execute several different kinds of compiled code (DDL seems to help
 here) - has garbage collection (D's GC should work)
 - perhaps an exokernel design (http://pdos.csail.mit.edu/exo.html)
 
 Name...
 Honestly, as long as it's not an achronym, I am all for it... So, name
 ideas anyone?
I'd put the garbage collector in the kernel, and if you want some memory, you have to ask him the permission! So there is one big gc for everyone. No ideas about shared libs etc. though... Carotinho
Didn't anybody *read* the exokernel ideas? GC can go in a library above exokernel and apps can use it if they like, or not. Regards, James Dunne
Oct 12 2005
next sibling parent Trevor Parscal <Trevor_member pathlink.com> writes:
In article <dike13$b70$1 digitaldaemon.com>, James Dunne says...
In article <dihjg2$4pc$1 digitaldaemon.com>, Carotinho says...
Trevor Parscal wrote:

 An Operating System In D...
 
 I have extreme ambition, tons of ideas, programming skills, and enough
 time to make a consistent effort. Perhaps I could get some help from some
 of you guys, and get a proof of concept together... Like pragma said...
 And yes, I have seen, and played with the beginings of a kernel in D that
 are posted on that wiki, and they should help us to get something together
 as well.
 
 Idea...
 A kernel
 - execute several different kinds of compiled code (DDL seems to help
 here) - has garbage collection (D's GC should work)
 - perhaps an exokernel design (http://pdos.csail.mit.edu/exo.html)
 
 Name...
 Honestly, as long as it's not an achronym, I am all for it... So, name
 ideas anyone?
I'd put the garbage collector in the kernel, and if you want some memory, you have to ask him the permission! So there is one big gc for everyone. No ideas about shared libs etc. though... Carotinho
Didn't anybody *read* the exokernel ideas? GC can go in a library above exokernel and apps can use it if they like, or not. Regards, James Dunne
Thats true... Well, the thing is, you could do it either way... So, I guess you would have to decide how you wanted to do it... Thanks, Trevor Parscal
Oct 12 2005
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
In article <dike13$b70$1 digitaldaemon.com>, James Dunne says...
Didn't anybody *read* the exokernel ideas?  GC can go in a library above
exokernel and apps can use it if they like, or not.
I went through the slide presentation. Pretty impressive stuff--I'm interested to hear how things go with their upcoming testing. Overall, I very much like the idea of a heavily modular OS, which exokernel seems to support quite well. Sean
Oct 12 2005
prev sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
James Dunne wrote:
 In article <dihjg2$4pc$1 digitaldaemon.com>, Carotinho says...
I'd put the garbage collector in the kernel, and if you want some memory,
you have to ask him the permission! So there is one big gc for everyone. No
ideas about shared libs etc. though...
Didn't anybody *read* the exokernel ideas? GC can go in a library above exokernel and apps can use it if they like, or not.
I say put the GC in a library (or actually multiple libraries, read on) for two reasons. One, allow programs to forego GC and use malloc()/free() if they so choose. Although in this case the kernel should probably still have some way of keeping a really close eye on things. Two, allow programs to select from a small collection of GC's of differing styles. Useful for people who, for example, really prefer a copying GC for their program (or whatever variety). Maybe instead of literally leaving out GC, malloc()/free() programs could be assigned to a special GC library that just implements those two traditional memory functions and some mechanism to keep on eye on the program, to make sure it doesn't step out of bounds, to be sure its memory doesn't leak on termination, for example. -- Chris Sauls
Oct 12 2005
parent Trevor Parscal <Trevor_member pathlink.com> writes:
In article <dikv03$1m7t$1 digitaldaemon.com>, Chris Sauls says...
James Dunne wrote:
 In article <dihjg2$4pc$1 digitaldaemon.com>, Carotinho says...
I'd put the garbage collector in the kernel, and if you want some memory,
you have to ask him the permission! So there is one big gc for everyone. No
ideas about shared libs etc. though...
Didn't anybody *read* the exokernel ideas? GC can go in a library above exokernel and apps can use it if they like, or not.
I say put the GC in a library (or actually multiple libraries, read on) for two reasons. One, allow programs to forego GC and use malloc()/free() if they so choose. Although in this case the kernel should probably still have some way of keeping a really close eye on things. Two, allow programs to select from a small collection of GC's of differing styles. Useful for people who, for example, really prefer a copying GC for their program (or whatever variety). Maybe instead of literally leaving out GC, malloc()/free() programs could be assigned to a special GC library that just implements those two traditional memory functions and some mechanism to keep on eye on the program, to make sure it doesn't step out of bounds, to be sure its memory doesn't leak on termination, for example. -- Chris Sauls
Very good ideas.. I agree that there should be choice in which type of GC, and also if you prefer not to use it at all.. And thats the great thing about an exokernel, the ability to put it all in a library... Titan should be modular... Thanks, Trevor Parscal
Oct 13 2005
prev sibling parent murpsoft hotmail.com writes:
~~~~~~~~~~~

Use D + D asm {}!
Everyone knows assembler is faster, but D is nicer to read.  Use D to manage the
namespaces, structures, etc, and use asm to write the speed-critical algorithms.
By DMA'ing in the whole OS within the bootloader/setup we could easily set up
the phobos.lib.  Using asmutils or libasm or something like that to implement
the "os" libraries makes sense (I think).

In terms of what the OS should do:

~~~~~~~~~~~~

How about removing support for obsolete hardware?  

Most operating systems still run code to manipulate the 8259 PIC controller, but
everyone since 1996 has had an APIC controller which completely supersets the
8259's capabilities.

Likewise with non-DMA, non-LBA disk drive access.  DMA/UDMA needs physical
access to the first 16Mb.  Most kernels use vm86 mode to provide that.  Yuck.
Try to look for a way around vm86 in graphics and you can completely not use it;
and the OS will be MUCH faster.

~~~~~~~~~~

How about using multi-threading and separating Code/Heap/Stack?

If you use a D array with an element for each agent, and for each agent give a
pointer to a code section/data section/stack section.  Organize it so that
adding permissions is adding an item to the control structure.  This is
Capabilities which is FAR more powerful than the current Permissions system.

To run code, the agent must have access to a code section.  The scheduler
doesn't need security - this alone provides an execute checkpoint.

We can run as many threads as we like without loading the code section more than
once.  The heap/stack must be fresh allocated for each thread.  Then we can
optionally memcpy the heap/stack from another thread and JMP to that thread's
current execution point (fork)

Agents can then EASILY use and exchange shared memory (grant the capability to
access a range of memory).  It doesn't even have to be page granular.  That
means we have three IPC protocols: one for exchanging capabilities, one for
ports, and one for exchanging messages that are too small and too infrequent to
warrant the use of shared memory.

Interestingly, Agents (programs) can also recieve more than one entry point
(just by having more than one code section) This allows us to provide IPC event
handlers, not just main(), so documentation, debugging etc, etc.

~~~~~~~~~~

Multithreading is MUCH easier with the above model, and in fact switching
threads is a simple matter; understand below pseudocode:

INT 0xNN ->

PUSHA; PUSH ES,DS;
MOV SS,[NEXT]; MOV ESP,[NEXT] 
POP DS,ES; POPA; IRET

That is the foundation of the thread-switch.  Everything else would be 
accounting/sleep/defer etc.

~~~~~

Drop a note, I'm clearly interested in the project.

http://murpsoft.com/
Oct 11 2005