Hello all,
I've designed an OS which is based on a Microkernel architecture and initially it will run on a x86 bochs machine. I have the functional analysis, but currently (I guess all new OS developers also) I don't know how to start.
Yes, I've readed the Getting Started (http://wiki.osdev.org/Getting_Started) and the Bare Bones tutorial (http://wiki.osdev.org/Bare_Bones). I'm not asking for development help at all, but for technical design tips. Recommendations from other programmers who successfully started an OS development project. I'm going to resume my project fastly:
In a simplistic point of view I want a LISP compiler written in C. That LISP "dialect" would be an "assembler language" in a LISP manner, a very low-level language. Having this, I would implement a macro system for generating LISP code (as Common LISP or Scheme does). The C compiler will evaluate that macros and generate the low-level LISP code, and then, compile it in x86 machine code.
The OS shell must:
1. Eval and compile LISP code.
2. Have access to the filesystem (I would like to implement a simple one, and rewrite it in a future).
I don't want yet access to Internet, nor GUI nor audio. I only want a shell.
I repeat myself again: I don't want help in the development at all. I want tips for designing the project, how to face the technical analysis.
Thank you all for reading and thanks for the OSDev Wiki.
PS: I moved myself the thread to the appropiate category.
PS2: If anyone wants/needs more information, feel free to ask in this thread.
OS as a Virtual Machine
Re: OS as a Virtual Machine
Hi,
Draw a diagram consisting of one box with "OS" written inside that box. Now, repeatedly follow these steps:
This basically describes "top down design, bottom up implementation" using a dynamically changing tree. Initially you'll be drawing lots of boxes; eventually the first thing you complete will probably be a boot loader; and one day you might end up with an empty tree/diagram.
Cheers,
Brendan
Draw a diagram consisting of one box with "OS" written inside that box. Now, repeatedly follow these steps:
- For each box that has no children:
- If that box can be completed then complete it and remove the box from your diagram
- If that box can't be completed, then:
- Determine how to split the work into several smaller pieces of work (e.g. "OS" might need to be spit into "micro-kernel", "LISP compiler", "Drivers" and "Applications")
- If any of those smaller pieces are already in your diagram, draw a line from current box to the existing child
- Put the remaining smaller pieces of work into the diagram as new child boxes
This basically describes "top down design, bottom up implementation" using a dynamically changing tree. Initially you'll be drawing lots of boxes; eventually the first thing you complete will probably be a boot loader; and one day you might end up with an empty tree/diagram.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
Re: OS as a Virtual Machine
You may find the book recommandations on the wiki useful.
PS: Since your OS will be LISP-based, it would be pretty cool for your shell to be a Lisp REPL.
PS: Since your OS will be LISP-based, it would be pretty cool for your shell to be a Lisp REPL.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
Re: OS as a Virtual Machine
Thank you for your replies.
I'll draw that tree, I hope it will help me across the development. That was a lot of help, I need a clear development path.
Yeah I want the shell to be a LISP REPL with a debugger. But maybe it's to complex at this moment. I'm going to implement the deugger later. hanks!
I'll draw that tree, I hope it will help me across the development. That was a lot of help, I need a clear development path.
Yeah I want the shell to be a LISP REPL with a debugger. But maybe it's to complex at this moment. I'm going to implement the deugger later. hanks!