Page 1 of 1

Sound like a good plan? Opinion needed.

Posted: Mon Apr 23, 2007 2:15 pm
by astrocrep
I have taken many stabs at OS dev in the past... I have messed around with mmurtl alot and hate the dated-ness of it and the fact that I need to used compilers from the early 1990s...

Over the past few days, I have become fairly farmilar with the Bran Example Kernel and am going to use that as a starting point for my OS Dev.

Below is my basic plan of attack. Basically, I am looking for your thoughts or ideas on it. My end goal is to have a simple GUI based os. I want the OS to be based around the GUI in the same fashion the BEOS is done. However, I understand that I need alot of underlying code before hacking away at a GUI.

What do you think?

1.) Compile Bran Exmaple Kernel
2.) Boot Bran Exmaple Kernel w/ grub
3.) Add Memory management
4.) Add Task switching
5.) Increase the depth of everything, enhance kyb driver
6.) IPC Message Exchange, Mailboxes, Add Wait, Sleep, Send, and other states to the T/S
6.) VM86 Task
7.) Floppy Driver
8.) Fat12/16 Support
9.) System Calls / Loadable App support
10.) VGA & Vesa 2.0 Drivers
11.) Font Sub system
12.) Mouse Driver
13.) Very Simple GUI
14.) Disk driver
15.) Fat32 Support

Thanks,
Rich

Posted: Mon Apr 23, 2007 2:41 pm
by Kevin McGuire
Maybe you should try to tackle device drivers before multi-tasking. That way you can get an idea of what you need the scheduler to do for the drivers. You also have to work with some sort of interrupt generating device to drive a scheduler if you decide to do a preemptive design; note I said device which should have some sort of driver code. Even if the driver code is embedded and relevant only to a certain kernel build.

You might want the disk driver before the GUI unless you decide to embed it into the kernel somehow, or in a form similar to driver that might support loading at compile or run time. Of course to do the later you would need some idea how you are going to do the drivers which should be essentially a module/image which needs to be loaded if at run time. If done for only compile time it might be nice to format it so it could easily be compiled and linked for run time loading with out rewriting the driver.

I dunno really. I figure there is no reason why the plan you have would not work, but there is doubt about the order in which you planned to do things will be the more efficient way. However if all else I would recommend doing it you're way since it might be the only effective way of learning.

Posted: Mon Apr 23, 2007 2:44 pm
by elderK
Not to mention Memory Management...

~zeii

Posted: Mon Apr 23, 2007 2:56 pm
by astrocrep
@Kevin: The bran kernel includes basic timer irq support. The idea is to use a floppy image. This way, I can do floppy drive and fat12 support and then be able to load files from the disk. After I get further down the road, Ill back peddle and introduce hdd and advanced filesystems.

Everything but 10,11,12 and 13 will be included in the kernel.

@zeii: Step 3 memory management.

Thanks,
Rich

Posted: Mon Apr 23, 2007 7:31 pm
by Crazed123
So I assume you've got the entire and complete design of your kernel made?

Posted: Mon Apr 23, 2007 7:36 pm
by Kevin McGuire
@Kevin: The bran kernel includes basic timer irq support. The idea is to use a floppy image. This way, I can do floppy drive and fat12 support and then be able to load files from the disk. After I get further down the road, Ill back peddle and introduce hdd and advanced filesystems.
Take another stab at it. It should be like learning to ride a bicycle in slow motion where seconds take weeks. No harm done if you do go about it the wrong way. I would like to see you come up with something usable or neat that can be shown off in the Project Announcements And Test Requests forum.

The plan you had was not bad or anything.