Yet Another OS

Avarok · Post by **Avarok** » Sun Sep 02, 2007 7:28 pm

Well, I've been a reverse engineer, D programmer, I've made a scripting engine and data mining tools. I've decided to start the big project.

Last night, with much reading and shamelessly peeking at other open source code, I wrote the boot loader. It gets me into 32 bit pmode with a20 enabled, and loads 19.5kb of empty space into 0x7e00-0xfcff for my initialization code.

My eventual objective is to provide an operating system built on Hans Reiser's FileSystem Semantics on Reiser4, pervasive multi-entrypoint multi-threading and event handlers, shared memory, capabilities, and strictly modern hardware support (64-bit only, no floppy drive support, etc)

To accomplish that, I need to:

1) Obtain a reiser4 filesystem implementation to support /metas/ like I see examples of everywhere, but isn't actually supported in Reiser4 anymore (even hand compiled, it seems)

2) Program reiser4 plugins to support my executable format capabilities.

3) Mount it in Linux.

4) Program the paging/dma/pio backend to properly put the file system into effect.

5) Figure it out, put module stubs in the filesystem and make my bootloader load them.

6) Do the other 99.9%

piranha · Post by **piranha** » Sun Sep 02, 2007 11:44 pm

You priorities are greatly out of order. First you need to get past the hello world stage.

And trust me, your going to want floppy drive support. Thats how you get things going.

Mods: This should be in Announcements, Test Requests, & Job openings.

-JL

Avarok · Post by **Avarok** » Mon Sep 03, 2007 2:29 am

piranha wrote:You priorities are greatly out of order. First you need to get past the hello world stage.

Well, the hello 32 bit world went down last night. The hello 64 bit world bypassing the 32 bit mode is being worked on today. Brendan did it, and I've got 90% of the conversion right at 5:20pm. Hopefully I can figure out my mistake before 8. I have work tomorrow.

At the moment it's hanging on

Code: Select all

mov cr0, eax
jmp 0x8:start64

I assume that means it's something wrong with my paging setup up to that point, since my 32 bit bootloader works fine, and I'm pretty sure I got the crX and MSR set correctly.

piranha wrote:And trust me, your going to want floppy drive support. Thats how you get things going.

I'm using Qemu, and I have a spare SATA2 hard disk, and I don't have any floppy drives. How convenient. I can admit though that I'm wishing I knew how to flag qemu to dump when the OS crashes.[/code]

piranha · Post by **piranha** » Mon Sep 03, 2007 12:27 pm

What about scheduling, memory management, and device drivers?

You need those before you can implement Reiser4

-JL

jerryleecooper · Post by **jerryleecooper** » Mon Sep 03, 2007 1:05 pm

Floppies is an obsolete technology, and some would say that making your own operating system is a megalomaniacal endeavour. But we know it's not the case.
I want my OS to support old computers so they don't get useless and goes to India and get people there sicks and dead.
Avarok, if you don't have a floppy drive and you are serious about os deving probably you should invest into an usb floppy drive?
And also, there's bochs if qemu isn't enough. That's what I use when I need more insight into wha'ts wrong with my kernel.

Avarok · Post by **Avarok** » Tue Sep 04, 2007 4:54 am

Yeah, I think I'll have to try to set that up. I vaguely remember trying Bochs a couple years ago, and it had this complicated configuration file stuff going instead of just running it.

Right now I've got hotkey compile + execution from SciTE to yasm to Qemu.

~~

The plan for the memory driver has been to force Agents (atomic security units/parties/programs/processes/users) to have specified in a configuration file, the memory allocation initial and maximum states, and then pre-allocate the initial and page-fault allocate up to maximum. No program other than the memory driver would have the capability to access the capabilities files for this.

The plan for the scheduler has been to force Agents to call (somehow) a thread creation routine which would take a pre-allocated stack and entry-point as arguments, as well as thread state and/or priority. The scheduler would then check the Agent's capabilities to see if it's allowed another (and even the first!) thread, and what it's allowed to request for state and/or priority and grant or deny the request. This makes files non-executable until explicitly defined as such by the system installer program.

For device drivers, the plan has been, so far, to implement shared memory via capabilities, and accept/deny direct hardware device access by overriding the appropriate system fault handler according to capabilities again. That in working order, the next step would be to *also* provide device drivers which wouldn't trigger the CPU exception.

There's more to think about, and I'm sure this isn't the best way, but I thought it would be sufficient for now. The design *mostly* attempts to follow exokernel theory via pervasive capabilities. The obvious exception being pre-allocation of some memory and the thread registration interface.

The plan was to implement these capabilities via Reiser4's improved small file handling, and a flag that enabled memory-only files (like tmpfs, but not a whole fs).

Since most of the OS should be stored on the filesystem, the idea was to create a disk image, which may or may not yet be loadable by the OS, rather than attempting to make an OS which we later fit into a disk image.

I've since seen though that this is less practical since the filesystem doesn't work with VFS and thus can't be run on Linux very readily. So instead I'll just create the program with awareness that in the future it will need to be hung on the FS (much like everyone else does).

So that's my train of thought.

JamesM · Post by **JamesM** » Tue Sep 04, 2007 7:20 am

The plan for the memory driver has been to force Agents (atomic security units/parties/programs/processes/users) to have specified in a configuration file, the memory allocation initial and maximum states, and then pre-allocate the initial and page-fault allocate up to maximum. No program other than the memory driver would have the capability to access the capabilities files for this.

Are you making a fully monolithic kernel then? If not, how will you load the disk driver process? It seems you are relying on the filesystem being fully operational before being able to launch processes. I would shy away from this myself, but that's personal preference.

JamesM

Avarok · Post by **Avarok** » Wed Sep 05, 2007 3:42 am

Well, I don't think so.. I'm designing the whole exokernel and critical system drivers as one cohesive design. They won't share a memory space, nor will they be mutually trusting or irreplaceable.

These modules are currently loaded up from the hard disk by the boot-loader via int 0x13. They're stored immediately behind the boot loader, rather than in a file like most OS's do, so perhaps I'm even *later* bound to the filesystem than most. Mine just linearly loads up the critical system drivers from the image (however many sectors I want).

At the moment I don't see why this ought to be changed. So I have no reason to implement a hard disk device driver to load up my memory driver or processor driver. It takes about 6 bytes to throw in another int 0x13 if I need another 40kb of code, but so far I don't think I'll need to explicitly do that.

The directories and files can (between when it comes and goes) use the page-fault handling mechanism to load the filesystem data up, once the filesystem code is in place, the page-fault handler is working, don't have proper non-fault-triggered DMA/PIO drivers up yet.

Make sense?