Operating Systems Checklist

[Mikemk]

I think there should be a checklist of things available to the general public about scrambling eggs (joking, about os development ).

These are what I know of:

1. Bootloader
   1. Master Boot Record
   2. 0xAA55
   3. Enter Protected Mode
2. ...

Feel free to add to it.

[gerryg400]

If it's a list of what's involved in writing an OS, it would be a very long list. And a list might not be the best way to present it.

Perhaps you're suggesting a list of things to do when booting a PC ? That could be managed as a list.

[Mikemk]

I'm suggesting a list with the things common among all OSs

[gerryg400]

I'm suggesting a list with the things common among all OSs

But those things are only a *small* part of the *early* boot sequence of an OS running on a *specific* machine (perhaps PC) with a *particular* type of firmware (BIOS). They actually have nothing at all to do with general OS development.

I'm not saying that there's anything wrong with making a list like you're suggesting...

[Mikemk]

It would still be quite helpful to new developers (like me)

[bluemoon]

Follow the tutorials, at some point you make departure from tutorials and you know what's next.
And no, MBR is not part of an OS, it's a supporting tool. Your OS should boot with any pre-installed MBR, if any.

[Mikemk]

The purpose of this topic was to create a checklist, for everyone, not to be told to "follow the tutorials"

[bluemoon]

The list will be either over-simplify like boot->init->load module->open a shell; or too complex to be listed. Seriously, you will know what's next if os developer is ready for it; otherwise, such a list would consist of difficult concepts that provide little help to starter.

[iansjack]

That list rules out Linux for starters, which relies on an external boot loader such as Grub. Many hobby OSs also use Grub, so those items don't apply. Bluemoon is correct to say that you are confusing boot loader with OS. Each OS, each processor, is different so a generic checklist is going to be difficult to draw up. None of what you list applies to an embedded OS on an ARM processor, for example.

A list would be so general to be useless. Something like:

1. Initialize processor and other hardware.
2. Manage memory.
3. Manage I/O.
4. Manage persistant storage (if any).
5. Manage processes (if any).
6. ...

Accurate, but not really helpful.

[Combuster]

The purpose of this topic was to create a checklist, for everyone, not to be told to "follow the tutorials"

The purpose of this thread is to tell you that there is no universal checklist that's actually meaningful. Even iansjack's "generic" list becomes wobbly when you throw good old DOS (don't manage, who cares anyway?) at it, and there are a few hobby OSes out there with a similar mindset.

Basically, the best list I can come up with is:
1: Design
2: Implement
3: Go to 1 (because nobody is perfect and you must have done something wrong somewhere. )

Your next best bet is What_order_should_I_make_things_in

[AndrewAPrice]

A OS checklist works upon the assumption that everyone will do things the same way. A single tasking OS may not want to do memory protection (I sure don't do paging or deal with virtual address spaces in my kernel).

What are you looking for? A checklist on what to do to enter protected/long mode? A checklist on how to make another POSIX clone?

[bluemoon]

If you're looking what people do in their init sequence, just for your reference, in my OS:

Stage 1

• Set CPU Flags and registers to known state
• Setup mini stack
• Export file reading functions for subsequent stages
• Load and pass control to stage 2

Stage 2

• Set CPU Flags and registers to known state again
• Re-setup mini stack
• Enable A20
• Get memory map
• Detect CPU
• For 32-bit CPU, load kernel32.bin and initrd32.bin into high memory, start kernel in 32-bit protected mode
• For 64-bit CPU, load kernel64.bin and initrd64.bin into high memory, start kernel in long mode with 2MB identity mapped paging

32-bit kernel

• Set CPU Flags and registers to known state again
• Clear BSS
• Paging & Higher-half
• Setup GDT
• Kernel mini stack
• Setup TSS
• Setup IDT(INT80 & exceptions)
• Setup MMU(mmap and unmap now usable)
• Setup PIC/APIC, IRQ handlers and Timer
• Initial scheduler
• Enable interrupts
• Load built-in drivers(ramdisk, initrd file system)
• HAL - detect hardware and setup more drivers from initrd
• Some testing code like running some test app in userland

64-bit kernel

• Set CPU Flags and registers to known state again
• Clear BSS
• Paging & Higher-half
• Setup GDT
• Kernel mini stack
• Setup TSS
• Setup syscall
• Setup IDT(exceptions)
• Setup MMU(mmap and unmap now usable)
• Setup PIC/APIC, IRQ handlers and Timer
• Initial scheduler
• Enable interrupts
• Load built-in drivers(ramdisk, initrd file system)
• HAL - detect hardware and setup more drivers from initrd
• Some testing code like running some test app in userland

You may notice my 32-bit & 64-bit kernel shares very similar workflow, and in fact they share most of the code except bootstrap, mmu, syscall entrance, program loader and context switching code.

[LindusSystem]

You told initial scheduler before enabling interrupts, what will you use as timer then?
NO INTERRUPTS(SO no IRQ 0 and 8)

[bluemoon]

I mean initialize scheduler, that was a typo.
there is some data structure to be initialized like setting "current process", etc.
Once it is initialized the timer can trigger scheduling.