OSDev.org

I was wondering if there is any strict order that I have to follow to write an os(kernel in particular). I know that some parts are absolutely crucial(such as user i/o), but then there are other parts that can wait(?). If I wanted to implement a file system, do I need to get all the other parts done first (paging, memory subsystem, etc...)?

You are guilty of not having read the sticky thread Quick Links - Read this before you post, which would have pointed you to (among other things) The OS FAQ, which as 4th item of the introduction has the page What order should I make things in.



Don't worry, I'd say about 85% of the newcomers get their first (few) question(s) answered like that.

I'm asking specifically whether I can jump right to the file system and design all of that other stuff later(providing that the file system isn't dependent on it, which I'm asking).

i think you should wait with things like filesystem etc.
my ideas of order:
1) make your kernel boot, grub or your own bootloader (including getting into pmode, set a20 and gdt)
2) make it (the kernel) print stuff (and set new gdt if necessary)
3) remap pics, mask irq?s, set up an idt
4) unmask irq 1, get keyboard input
.....

that depends on how you gonna organize your file system subsystem: a process of its own (micro kernel approach) or a set of functions/modules accessible by a ell defined set of interface functions (monolithic kernel)

I'd recommend you begin with the low level stuff - and provide yourself with a decent k_printf for doing debug stuff.

->inport()/outport()
->memset(),memcpy()
->malloc(),free()

write interrupt service routine stubs in asm - they are so general you can write one macro and use that in the very lowest layer of your kernel - (I 've actually called the file "lowlevel.asm" *gg*) - for servicing interrupts and exceptions - and performing taskswitches. That's gonna keep you busy for quite some time I reckon. ];->

@solar: *gg* testy man. The poor n00bs.

You could implement a FS before complete memory management, but it would mean you'll always have to declare static arrays everyware to know where data will be stored.

Moreover, programming a FS in a monotasking, unpaged environment or in a multitasking, multispaced paged environment will require very different coding (imho), so the monotasked code will probably be good for recycling later on ...

personally, I opp to:

• Research
• Start with GRUB. It's usefull ;D
• Get a down&dirty screen.c going (i call it screen. some call it terminal..etc.)
• Make some debugging tools on top of your existing setup