I’ve just committed to the SVN the latest and greatest version of the kernel. I’m trying to figure out how to place all the bricks in the virtual space in a logical and meaningful way while keeping all the things as small as possible. For the moment I chose a very simple, classic and pretty space-wasting layout:

HEAP
0xf0000000 -> 0xfbffffff

KERNEL code (.text, .data, .bss)
0xfc000000 -> 0xffffffff

This means that there are up to 64MB reserved for all the kernel’s almost static things (code, initialized and uninitialized data, stack…) and up to 192MB of pure heap galore. I’m looking forward to keep all the things tight in order to leave the largest possible share of virtual space for the user land. I’ve also set up a structure type called mmap_block that is a linked list node to represent the physical memory map¹ divided in available and taken chunks of variable size.

/**
 * Enumerates the possible mmap_block.available states.
 * MMAP_INVALID: This doesn't describe a valid block, thus it is available for
 * describing a new block;
 * MMAP_FREE: This describes a free memory chunk;
 * MMAP_ALLOC: This describes an allocated chunk of memory;
 * MMAP_RESERVED: This describes a special chunk of memory that shouldn't be
 * touched.
 */
enum mmap_avl { MMAP_INVALID, MMAP_FREE, MMAP_ALLOC, MMAP_RESERVED };
 
typedef struct mmap_block_s {
#if __BITS__ == 32
	u32 base_32;
	u32 size_32;
#else
	union {
		struct {
			u32 low;
			u32 high;
		} base_32;
		u64 base_64;
	};
	union {
		struct {
			u32 low;
			u32 high;
		} size_32;
		u64 size_64;
	};
#endif
	enum mmap_avl		available	: 2;	// See enum mmap_avl above
	u32			flags		: 30;	// Reserved for future expansion
	u32			pid;			// The pid of the owner process
	struct mmap_block_s	*next;
	struct mmap_block_s	*prev;
} mmap_block;		// 24/32B

This structure is intended to allocate memory by chunks of 4kB, thus requiring at most 24MB to cover the whole addressing space on a 32 bit arch. The initial layout is built inside the kernel’s heap to be both easily available from the code and easily extensible as needed. It is (somehow) based on the memory map built by the lovely GRUB taking into account the things that GRUB just can’t be aware of².

The very next step will be a low level kernel allocator that can give pointers to free memory and allocate new pages and memory chunks as needed.

1. At this very moment it represents the entire 4GB addressing space due to my laziness in checking things around [↩]
2. The kernel itself, the heap and so on… [↩]

tOfuS, the musicians’ operating system.

It has gone further since the early days when it was just saying “Hello world” after some bits and bytes of assembly. It is now starting to face the virtual memory management and some other weird topics. This all together persuaded me to finally restate my goals and reopen this website.

tOfuS’ now much more than a shy attempt to boot from a floppy disk and experiment with assembly on a bare machine and it also has become much less than the greatly promoted “musicians’ operating system”. It is now officially a hobby OS, which is to me mainly a way to take a look at how kernels work without having to look at the work of someone else - that is always more complicated than it should. It is also intended to be an easy-to-understand code base for everyone to study on and an easy-to-use framework for simple implementations of various algorithms that one day might become real implementations for some real OS¹.

If you’re interested in the project you may take a look at the dev wiki - that is, by now, pretty empty. I’m also planning to put on paper the main guidelines for anybody that may become interested in using tOfuS for experiments and contribute to the growth of the project.

So here we are, hello world.

1. so to speak, tOfuS is intelligent design (and a bit of evolution too) [↩]