Saturday, 9 July 2011

Major break through

I know this post is a little early, but I don't care, since we have had this major breakthrough last nigt.

It doesn't seem like much, but if you're a little familiar with the project you'll realise that the fact that we have Elf loading working, is a HUGE thing.

The reason why it such an impressive feat is because everything has been made from scratch.
"So?" You might ask.

Well, We've had to initialise a heap, use that heap (did that with a first fit algorithm), print some text to screen, and set up paging.

The first big breakthrough was when I had a heap working, the second was paging, even though that one isn't really finished yet. The last in this sequence is Elf loading, since it puts every thing together.

It basically pulls the interesting stuff out of the image and pasts it somewhere in memory (defined by the image). The weird thing is that the batch of memory requested might not even exist. That's difficult since we actually need it.

Not to worry, we have a way of doing things to make this all possible. It's called virtual memory. Basically what it does is split the address space up into 4KB pages, and a page is then connected to a physical batch of memory, allowing for pages to exist in memory addresses which don't exist in the physical address space.

This does however come with a problem. Since the virtual address space is 4 GB in size and the actual memory size is something random, that might spawn the problem of a lack of physical memory. Now that's solved by swapping the pages out to disk.

This however hasn't been implemented, which has a very simple reason. We don't have file system support, and thus we aren't able to write to or read from disk.

Guess what's up next in the planning?

Well, yes, graphics, but besides that?

Indeed, file systems support. This will likely be a three tier approach.
Tier 1: The virtual filesystem (vfs), this is what you interface with as user/programmer.
Tier 2: The filesystem driver(fs driver), which is what looks up the physical position on a physical hard drive, regardless of what type of drive you use.
Tier 3: The disk driver, which takes commands from the filesystem driver to access specific blocks on the drive, without the need to know about filesystems.

How this will be implemented needs some thinking though. Are we going to implement the inodes in the vfs, or will that be supported in the fs driver, and if so where will we keep track of mount points.

If you have ideas, they're always welcome of course.

Another thing that desperately needs to be done is the design of a logo. Now for more info go here.

1 comment:

  1. Maybe you whould like to copy your blog post to the new website...

    ReplyDelete