Help me with x86 kernel :)

[bartekww]

Hey. Im writing my first kernel. I have vga done. What should be next?

[Bender]

"What should be next?" is a type of question people ask when they don't know what they're doing. What you're supposed to do next is your choice.
Being said that there was a similar post a few days ago. The answers there might help to get the stone gain momentum.
http://forum.osdev.org/viewtopic.php?f= ... 9&p=237291

[Combuster]

Oh look, I've seen this question before: FAQ

[SpyderTL]

If you are just asking our opinion, I'd say a mouse driver would be next, if you are already in VGA (non-text) mode.

It's not too difficult to read from the PS/2 mouse controller. The hardest part is probably keeping track of an entire packet when you receive one byte at a time.

Also, sending commands to configure the controller is a little annoying.

[iansjack]

If you have "VGA done" (not quite sure what you mean by that), then you have a means of outputting data. Another useful facility would be the ability to input data. A mouse driver is one possibility, but I would say a keyboard driver would be more useful. That allows a good variety of data input and goes a long way towards making a command shell possible.

[Peterbjornx]

learn some more.

Seriously, though: I would not recommend doing input just yet, implement an exception handler first, then a heap manager, physical memory manager first, then paging support, once you have done that you can move on to fun things such as multitasking and a VFS

[Marionumber1]

learn some more.

Seriously, though: I would not recommend doing input just yet, implement an exception handler first, then a heap manager, physical memory manager first, then paging support, once you have done that you can move on to fun things such as multitasking and a VFS

Wouldn't a heap manager depend on both the physical memory manager and paging?

[Velko]

Wouldn't a heap manager depend on both the physical memory manager and paging?

Actually - no, sort of.

Yes, you need PMM and paging when existing heap becomes full and you need to expand it. But if you pre-seed your heap with some amount of RAM early on boot, it will serve its purpose well, until you got other subsystems online.

My kernel initializes heap with 128KiB of RAM (reserved using .bss-like section), and I am not sure if it ever got to the point where it needs expanding. More fun: my PMM initialization actually depends on working malloc().

[Candy]

@OP:

1. What are you trying to make?

Call that your goal. Now, that goal is a pretty far away and big chunk of work. Let's split it up into things that you can actually achieve.

2. What is the very next thing you can visibly demonstrate that has some form of relevance? Think "Hello world on screen", "bootup sound plays", "first client process runs", "login screen visible" or something along those lines. It should be easy to check and hard to achieve, and preferably include a few, but not too many new subsystems.

That's your next "epic". To get there you have an idea about what the system should do and what components you need. Try to design what those components should do and how they should interact, but only insofar as this one epic requires it. So to display the login screen, you should limit the UI manager to "display one window in the middle of the screen" and the text rendering methods to "can render this static line of login text". Don't overengineer systems.

3. Which of those can you work on right now and get it to the required state?

That's your next task to pick up. Go do that, get it done and have some form of checking (test, manual probing, whichever) to see that it's done. Repeat that to finish tasks, until you think you have done the epic - then check that you have done that, go to the next.

I find this way of working to keep my spirits & motivation up the most and to always have something concrete to pick up, while also always knowing what I'm going to have to show off next. The epics are always at the exact "heart-banging-shivers-on-my-back" moment of ohmygoditworks.

To illustrate, I'm working on my own OS:

Goal: OS that allows basic usage (browsing, text editing) in a user-friendly environment.
Epics:
- Have it print a stack trace of an exception with symbols <-- This one is in the screenshot thread I think
- Have it get an IP address while running in an emulator (qemu with rtl8139) <-- This one is too.
- Have it get an IP address & be pingable while running on a real machine (with rtl8139, rtl8169 or e1000 NIC) <-- I'm working towards this goal now, with a few troubles in getting the code running for E1000.
- Have it start a client-space program in its own address space that can display a window on an emulator <-- For this one I know I have a lot of code already that I just need to bang into shape again
- Have it download and display the HTML page of "http://forum.osdev.org/" as text (ie, just raw dump) on screen <-- This is adding the TCP connection stuff, some interface between user and kernel space to get it there and then adding basic HTTP support.