What should a kernel have?

[gabemaiberger]

I have a kernel that has a basic printing function, an error function, a GDT, the ability to switch from real mode and back and a semi working idt. What else should a fully functional mature protected-mode kernel have?

[iansjack]

That's rather an open-ended question, isn't it. It all depends upon what you want your kernel to do. Accept user input? Then you'll need a keyboard handler. Run programs? Then you'll need the ability to create a process and have it run a particular selection of code. You'll probably want to load that code from somewhere, so that requires a disk driver or something similar. And so on, and so on.

What did you have in mind when you started on your kernel? Well that's what you want to do next - eventually. You may find that you need to satisfy a few intermediate goals before you can fulfil that ultimate goal.

[Casm]

Memory manager(s)
Dispatcher
Default device drivers for the monitor, keyboard, hard disk and DVD drive.
System services.
Possibly the default file system.
Interrupt and exception handlers.
Inter process communication.

[chickendinner]

The next stop in a typical OS dev roadmap would memory management.

Make sure your print function has the ability to print numbers and addresses. Lookup a decent c runtime itoa() implementation to see how to do this, have it work with 64bit numbers as a standard implementation works with 32bit signed integers and you won't be able to print all the addresses. This will help no end when building a memory manager, an alternative would be to use a debugger to inspect memory locations of variables, but for this task it would probably be slower (It would be good practice to get familiar with using one with your VM however).

If you're choosing to write a typical 32bit protected mode operating system with paging then you would do this:

• First get a map of what memory is usable. If you're using a multiboot compliant bootloader there will be a pointer to a structure with a memory map pointer in it passed to your kernel (Read the multiboot spec for more details http://www.gnu.org/software/grub/manual ... iboot.html). See here http://wiki.osdev.org/Detecting_Memory_(x86) under the e820 section to see how the map is structured or how to do it manually.
• Create a physical memory manager. Do this by representing that memory map in some way, for example a linked list or a bitmap. Write a routine that you can call to take a 4kb (aligned on a 4kb page boundary) block of memory out of it and put it back in.
• See these guides here http://wiki.osdev.org/Paging and here http://wiki.osdev.org/Setting_Up_Paging. To set up your page table manager. Write a method that can take a physical address and a virtual address argument along with a protection level that places the correct entry in the page table, along with one to deallocate an entry.
• Put it all together by writing a malloc routine that when asked requests memory from your physical memory manager and then maps it in the page table manager. And a routine that frees it.

You now have a memory manager. The next steps would be:

• Load a unprivileged program into memory inside it's own address space. I would just link a flat program binary in with the kernel or have the bootloader do it for me (Take a look at the multiboot specification for that) for now and deal with filesystems/reading sectors from a device until later when you have a foundation of a kernel to support a sophisticated driver.
• Write a syscall interface so that program can call privileged kernel functions.
• Write a task switcher hooked up to the interval timer IRQ to switch between multiple programs.
• Build newlib ontop of your syscalls so your programs can use the C runtime library.

You'll then have the core functionality of a kernel to extend with IPC/SMP/Device drivers/file system support and a UI of some sort.