OSDev.org

Hello!
Im working on my os, and i have initialized the IDT, GDT, ISRs and IRQs.
Also set the videomode and fixed the keyboard "driver".
So currently the OS looks like this:
http://statestik.com/os/camelia2.png

But now i have two choices:
1. should i implent the Shell into the kernel.
2. should i make the kernel launch an executable?

the first one i probably the most easy way to do it, but if i could make it launch an executable shell, then i should get two flies in one punch? (one shell and one way of executing binarys) =)

What do you think?
Ideas are welcome =)

//ZetItUp

one usually avoids to implement the shell at kernel level ... when the system is done. You might find it easier to have a sort of "systemshell" that allows you to do things while the interface with usermode isn't completed.

hi,

I would suggest to do the executable loading and executing first, because it's rather easy to load e.g. elf executable.

i actually would have to (at least partially disagree here). Both while in college taking an OS course and now with my personal project OS, having a kernel level shell (a very simple one at least) was VERY helpful with developing the other features).

It is a great way to test certain features before you get user space apps and syscalls. For example one of the first things i did in my OS was get kernel mode threads going, how to test?

well i added a "threads" command to my kernel shell which spun off 26 threads, 5 lines of code and i can test it.

obviously this will be removed in the long term, but while developing it is very useful.

proxy

proxy wrote: well i added a "threads" command to my kernel shell which spun off 26 threads, 5 lines of code and i can test it.

Yep. It all depend on what's available on your kernel. In clicker, the same "test case" is usually achieved by creating a "tester module" that can be loaded by the "module manager" on request.
(that makes it much like a shell, except it doesn't look like one, but it still waits for user input to select some program to be loaded and reports result of program operation).

Very basically, you might end up with
- some kernel-hosted code that parses and execute user commands
- some kernel-hosted code that loads code for user command
- kernel-hosted code that loads parsing and command code.

I've done that too. Including snme command parsing into the kernel to faciliate testing.

Nowadays I'm thinking of something like a debug shell - a thread in Kernel and a user app communicating with that thread - to get hands at crucial info if something goes haywire. Well - Time tells. Studying takes quite some time away from os deving.

You should setup a way to print hexidecimal numbers to the screen as it will be useful for debugging.

Now you must also setup a GDT with atleast 3 entries. Null, Code, Data.

Logically, the next thing one would do is handle exceptions and interrupts
(Setup the entries in the IDT for each IRQ and ISR then write stubs for them in assembly to optionally call C functions)

I'd write a memory manager next since that is needed before you can do most of the other things. There is a bunch of information on the OSFaq (Click on the Mega-Tokyo picture above) which explain how memory management works and Brendan has taken time to explain it in great detail in other topics. If you head down to Bona Fide (www.osdever.net) Tim Robinson has written two tutorials on memory management as well.

After this the decisions really up to you. The OSFaq has a page about paths to take during OSDev which can offer some type of roadmap to what you want to do but really this is stuff you just need to think about on your own.

Good luck.