beeos

[beeos]

6/15/20: Memory map

Just a small update on my progress today.

1: Examined the memory map buffer of the multiboot information struct. Now I know how to access available RAM, which means I can start playing with memory.

2: Currently reading up on paging and memory management. Trying to figure out what I need to worry about now, since I’m only writing kernel stuff at the moment. Not sure if I should turn on paging or not. Not sure if I should start with writing processes/threads.

[beeos]

6/14/20: Bootloader days are over?

WOO! LOOK AT THIS!

Trying to roll my own bootloader was not the best idea. I got grub2 set up relatively quickly (read: in a freaking day!). Today I edited Bran’s template code to output as elf32 rather than a.out.

From here, getting the GDT loaded in and putting the BIOS functions together was *so* easy. I already had a GDT descriptor table set up from before, which could be included and easily called (via the lgdt instruction). And, my screen I/O code from before also worked just fine. So, voila! I got my code to compile and boot successfully, and my kernel can print messages to the screen!

Well, there was a bit of trouble with the linker. I spent a while reading the documentation, which helped me fix up the Bran’s template linker. However, I accidentally created an issue with the “.” location counter, which ended up taking me most of the day to debug... But I got it fixed, and ultimately everything booted up properly, so I’m happy :)

Next steps:

1: Look into SMP. I want to design with multiprocessor support in mind from the beginning, because that would be REALLY cool and would allow me to explore some of the implementation complications we discussed in class. So, I’ll need to figure out how to actually... use? multiprocessors?... This will probably be a small headache, especially since I am expecting that it will require some deeper hardware knowledge and assembler.

2: I guess my first big project from here, if I’m following the trajectory used for Weenix, would be processes. How does this relate to threads? I’ll have to look into this more.

In the back of my mind: Ah jeez, eventually I should figure out how to make the Makefile more useful. For the time being, and while the project is still small, I will just manually update the commands for each file :P

Also, after glancing at some other hobby OS projects, I think I should eventually look into VESA graphics to get a pretty user-land. That is still a ways off, though.

On a related note, I think I should probably take a moment to think about what my goals for this project are. Primarily, I just want to keep learning this summer, since I don’t really have any other obligations. I think I’m drawn to operating systems because 1) it’s the most recent topic I learned in class and 2) I’ve been really enjoying the process of “understanding” computers over the past year, starting with intro systems, and then extending into the x86 security class and networks, and then operating systems and my little IT job at the computer lab. So, taking some time to hammer out my understanding of the details that I didn’t entirely grasp in my os class last semester would be nice.

But, on the level of, “what are the goals for this operating system?”, insofar as it motivates my design decisions: I am aware that whatever I make will always be a hobby operating system. So, to that extent, I think it’s safe to say that this project is primarily a learning tool for me to try my hand at implementing not only a functioning OS, but one with some of the more complicated advancements we covered in class (”advancements” relative to very early systems, lol).

I think POSIX compliance should not be a concern, since porting is not really that important here. After all, who’s gonna be using this, and how much? Nevertheless, just because of my familiarity with Unix-like systems, I will probably be following major POSIX conventions pretty closely.

This means I’m not really following any particular specifications, which then means I actually have quite a bit of freedom with my design decisions. For the time being, I’ll just try my best to model around the solutions we discussed in class. I think something else I should do is start writing out a general design plan for the system so I know how the pieces will fit together. Then, as I start coding and testing, maybe I’ll come up with my own ideas for neat solutions or features to experiment with!

Anyway, that closes it for today. I’ve been pretty active posting lately, and hopefully that continues. However, I suspect that progress will begin slowing down now that I’m past the bootloader stuff and now really need to be thinking about the “grand design”. But, writing these posts has been a lot of fun, so maybe I’ll keep it up!

[beeos]

6/13/20: Grub

So evidently getting grub to work is *very* simple. This just goes to show how draining it can be trying to parse through documentation and half-baked tutorials to figure out what I need to do.

Well anyway, the good news is, after a lot of struggling today, I figured out how to create an .iso file using grub, which can then be run with qemu as a CD-ROM! This is an *incredibly* small step, but it feels good to end the day with some sense of completion.

On the horizon: Now I need to reexamine the template code I have been using from Bran’s tutorial. Plans for tomorrow:

1: Figure out: How does the linker.ld script work? This is clearly very important since I can use it to control where the linker puts things in the final executable.

2: Load in the GDT. This shouldn’t be too hard, since I already have the code for when I did that in my original bootloader.

3: Get the multiboot assembler code to call main(). This also entails that I write a simple main(), and get it to compile properly.

From here, the next coding test will be to write a very simple library to allow I/O with the video memory. Once I have figured out a good (read: acceptable) way to compile various .c and .h files, I will probably be pretty much “set” to start coding actual modules.

Until next time!

[beeos]

6/12/20: Initial Post

Wow, first off, how is it already June 12th? Golly, doing “nothing” sure passes you by pretty quickly.

Well, my progress so far is simultaneously a lot and a little. For the past month(!) I have been doing two things:

1) Trying to write a bootloader (AGH!).

2) Reviewing the material from my operating systems class by rereading the class textbook (Operating Systems in Depth, Doeppner).

The first has been incredibly frustrating. Setting up the proper environment was mostly a matter of figuring out configurations. The bootloader itself has so many architectural quirks, and even though I am somewhat glad that I went to the work of “writing” one, I think I could have done without it. I especially say this because I think my plan now is to scrap what I have so far and just use GRUB.

Indeed, I think my primary immediate goal is to figure out how to use GRUB to create a very simple but extensible bootable image upon which I can begin writing actual C code. Mostly, I just want to get out of this nightmarish bootloading woods that has haunted me for the past month, and move on to actually writing an operating system.

Taking the time to actually read the textbook for real has been really good. Mostly, I think it filled in a lot of holes I had from lecture, because the format of the information is “survey-like”, as it covers concepts from various operating systems. I think the lectures did not really delineate each concept very well, so they blended together a bit, which was very confusing. But now I have a much better understanding of the, let’s say, “identity”, of the various concepts that were presented.

In doing so, I think I have a pretty good idea of what needs to be done to achieve a “well-designed” simple operating system. Basic goals are probably: multiprocessor support for multithreaded processes, a “good” file system, and virtual memory, in order to support a “good” user land. From here, POSIX-compliance would be cool, along with an actual visual interface. As I go along, I’ll probably carve out more detailed goals.

Anyway, for the sake of holding myself accountable in some nonzero way, I’ll be trying to make a progress post next week, June 19th. Hopefully by then, I’ll have gotten GRUB to work with me and will have begun working on the more high-level design of the operating system (e.g. implementation goals, data structures, etc...).