What to do after Bare Bones

[Xunil]

I've used the Bare bones tutorials to make a simple OS in C++ that displays text. Where should I go from here? I probably need some memory management, I guess...

Can anybody tell me what I should do now?

[JackScott]

As a rough guide, you want to do three things simultaneously, all through development:

• Implement back-end stuff (ie the kernel core)
• Implement front-end stuff (a user interface)
• Come up with a solid design, and make sure your code fits that design.

Some people do design, then back-end, then front-end. I argue it'll be much more interesting if you do a bit of each, while keeping the others in mind. As for specifics:

• Set up a GDT, an IDT (and a basic fault handler), and if you are going to be using it, paging.
• You need a solid way to input and output text to the kernel to debug it (printf, scanf, etc). Eventually these routines will become a user interface.
• Spend a bit of time thinking about the build environment. Creating a makefile to automate builds is a great idea, and is helpful for even the smallest kernel.
• Think about how you want the user to interact with the computer. Not on a graphical level, that is of no importance yet. But on a semantic level. Is it batch-based? Is it multi-user, multi-tasking, multi-node, super computing? These questions will guide your design.

Though ultimately, what you do next (and beyond that) is up to you.

[Xunil]

Thanks for the reply, it was really helpful. I think I'll begin with the text output methods, and then do the GDT and IDT.

[Creature]

I mostly followed JamesM's code and did some things in between, here's in what order I did things, if it's of any help to you:

• Created multiboot header for GRUB and entry point.
• Wrote some C++ support code (of course this is only necessary if you're coding in C++).
• Wrote some C standard functions, like strcpy and memcpy and some other basic port I/O functions like the traditional inb and outb.
• Wrote the GDT, IDT, support for IRQ's and ISR's.
• Console text output support.
• Keyboard driver.
• Paging.
• Heap.
• Input driver, shell.
• ...

Things like 'keyboard driver' at that time usually were very basic, which became more advanced while implementing other things. After that you can still do things like floppy support, hard disk writing/reading, FAT12/16/32 support, multitasking, program loading, and so on.

[gravaera]

I'm currently undertaking a massive design phase. I'm leaving the bootloader for later, though: In fact, I'm actually thinking about releasing my Os with GrUB, if anything. Why make it Multiboot, if I don't use a multiboot bootloader?

Design has so far catered for the API, and interrupts, and the "Stream" scheme I discussed earlier. I'm planning to have modular kernel that has nothing more than a tie-iin module to handle calls to the Os. Upon recieving a call, the OS translates the call down to an API function, and jumps to the code in memory that is contained in a Shared ELF module.

My implementation should go in the order of:

1. ELF Support
2. STD Lib (custom)
3. Hardware Framework (not drivers yet)
4. Kernel Loader module which loads the ELF modules into memory in a protected page range
5. Kernel Tie-In module (the actual kernel), which terminates the Kernel Loader after being called by it, and holds a symbol table and string table for all syscalls.

The 5th one means that the kernel itself is pretty much the API wrapper. I don't want to implement Software Interrupts. I think it's very impractical. I just never liked interrupts myself. Syscalls are more logical and more orderly. There's nothing wrong with me just requiring ASM developers to do an EXTERN __zos_foo line.

In fact I think they'll like it better: interrupts require you to remember different values for different registers, etc. (mov ax 4c00h)

[Xunil]

Just a quick question...

When I declare a function in one file and define it in another, I get this error:

Code: Select all

main.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'

Anybody knows why? I do link both files together. And it only happens when declaration and definition is in different files...

[pcmattman]

Code: Select all

.eh_frame

Use "-fno-exceptions". The Wiki has a page with gotchas like this.

[Xunil]

Code: Select all

.eh_frame

Use "-fno-exceptions". The Wiki has a page with gotchas like this.

Thanks, it worked!

[Xunil]

I have another problem...

I'm setting up the GDT, and I have this function in gdt.h:

Code: Select all

extern void _gdt_flush(u32int);

and in my assembly code, it is defined as global:

Code: Select all

global _gdt_flush

(and I also got the _gdt_flush function declared ofc)
and I call the function from gtd.cpp:

Code: Select all

_gdt_flush((u32int)&gdt_ptr);

But when I link it, I get this error:

Code: Select all

gdt.cpp:(.text+0x174): undefined reference to `_gdt_flush(unsigned int)'

I do compile with -fno-leading-underscore. What could there problem be?

[Creature]

In C++, you must use C linkage to get simpler symbol names, try extern "C" void _gdt_flush.

[alethiophile]

The 5th one means that the kernel itself is pretty much the API wrapper. I don't want to implement Software Interrupts. I think it's very impractical. I just never liked interrupts myself. Syscalls are more logical and more orderly. There's nothing wrong with me just requiring ASM developers to do an EXTERN __zos_foo line.

I'm not sure how that would work. Wouldn't it require that all the user programs be linked in with the kernel (in effect, be kernel modules)?

[gravaera]

Yup. It would mean I'll have to develop a compiler. I'm not sure how well that will work out, though. But by the time I'm ready to add general application support, I think I'd have found some partners to work with me.

I hope.

[mathematician]

I've used the Bare bones tutorials to make a simple OS in C++ that displays text. Where should I go from here? I probably need some memory management, I guess...

Can anybody tell me what I should do now?

Even from an early stage you are going to be loading files from a real or virtue disk, so you might want to get the meta data (directory, inodes etc) down onto disk. You won't be writing a file system driver just yet, but you can write some crude utilities to get your operating system files onto, and off, of the disk. After that you might want keyboard input and text output, and, since you cannot go on with the ad hoc allocation of memory forever, a memory manager.