Where to go from here? [Hello World Kernel]

[XeonX369]

Hello everyone, I am new to the world of OSDev and am wondering where to go from here.

I have recently built a fully functional bootsector which searches for the kernel in designated boot space.
I have, from there, built a simple working kernel (basically a hello world with a few other functions.)

My main issue here is that I can't figure out where to go from here. I have conjured many ideas such as implementing my own version of a C library, but I also want to write a few low-level functions (???macros???) so that I can build some system dependent programs. I am looking for people experienced with this to help me in my quest. So-far, my Kernel built is Monolithic, but I eventually want to work upto a Hybrid Kernel with a special space for system processes (a psudo-user-space), any advice on this.

I also am looking for a way to preserve my partition table (using dd) and would like some advice on that aspect of copying a bootsector.

Thanks for all the help.

[Combuster]

My main issue here is that I can't figure out where to go from here.

You just asked a frequently asked question - FAQ (What order should I make things in?)

[XeonX369]

Yes, I see that, but it provided me with little in the way of actually inspiring me with ideas. Am I having issues of confidence ... what should I do, please help...

[neon]

If the kernel is that simple, why not just expand the kernel while working on the C library as needed? Memory Management, Task Management, from there it depends: Multitasking or not? Graphical or not? Mabey put the kernel on hold and write a driver or two?

If you dont know what you would like to do next, just pick one at random and do it.

[kmcguire]

I remember when I was writting a kernel and I got to the point where I had a simple "hello world" program.

I also remember that the next step I took was learning about the virtual memory features of the 80386, and I think during that time I also started trying to implement a processes and threads. It is a little tricky because both normally work together. A process normally has it's own virtual address space.

You might try writting routines to create a page directory and manipulate it's structures, flags, and tables. Make sure to have them able to manipulate arbitray page directories because you are going to want to handle multiple page directories (one for each process). Learn how to provide a kernel and user space for each page directory. So that the kernel can always reside at the same region in virtual address space for each process (using the page directory).

I would imagine also learning about the TSS so you can easily switch between priviledge levels and implement task switching which will form the basis for switching between threads in a process which are in their own virtual address space. You do not have to be stuck with the hardware limit on the number of TSS structures (from the entry limit of the GDT -- I think 0xFFFE roughly?). There are techniques to overcome this limitation so keep that in mind when working.

If you support some legacy devices your memory management routines will need to be able to handle saving some memory regions which are used by legacy devices. You also need to be able to get a rough map of what memory is free and what is not and this might change as the system is booted when certain devices can not be remapped and others can.

So to make a summary. 1. Functions to manipulate individual page directories and tables (and change current page directory CR3 and flush caches). 2. Functions to manipulate process and thread structures and implement a simple scheduler which uses at least one TSS structure and some type of hardware time to call the switching routine.

Past this point you should start working with drivers. Implementing IRQ routing. Yes, IRQ needs to be routed to the correct driver. Also abstractions for certain classes of hardware and buses. This is where you would start writting some type of device management system.. filesystem drivers.. pci bus driver.. Some drivers may prefer to create a thread to handle an IRQ and some may want to perform some action right there and then. This will require a task switching implementation (threads at the least) and memory management.

[kubeos]

I never actually planned anything at the start. I just implemented things as the need arose. I implemented a memory manager, multi-tasking, and some basic input and output drivers after I got to the 'hello world' point. From there I moved on to floppy, hd, and file system drivers. When I could load a file I started working on syscalls and a tiny libc for testing.

[XeonX369]

Thanks to all who contributed in this discussion,

I must say: at the start of this endeavor, I felt a slight bit overwhelmed. With all of your recommendations, I believe that I will work on a memory model first (Paging most likely) and then on a few handlers for things such a complex input, and maybe some basic drivers and see where that takes me.

Many ... many thanks to all who have contributed/helped and who continue to do so!

[gravaera]

Hi:

I'm not trying to bash you, but based on your topic http://forum.osdev.org/viewtopic.php?f=1&t=20998 and the general impression you gave in this topic as well, I'd like to impress upon you that you have yet a lot of reading to do.

but I also want to write a few low-level functions (???macros???) so that I can build some system dependent programs

If by "System dependent Programs" you mean programs that rely on your OS' API, and kernel provided functions, I believe that you should look into getting the basics down: You need a scheduler, Memory Protection (implementable through Paging), Dynamic Memory Allocation, a basic set of Disk and VFS drivers, and what accompanies those, some ELF, PE, or other Exec. File Format loaders, a real kernel API which should, (optimally) be presented to apps via shared libraries, and lots of other stuff.

I didn't quite get the macro part, and how it relates to low-level programming, though. If it's the C preprocessor macro facility you're talking about, I'm afraid that's the wrong idea.

I also am looking for a way to preserve my partition table (using dd) and would like some advice on that aspect of copying a bootsector.

IIRC, the bootsector is the absolute first sector on a disk. There should be no problem accessing and writing to that. You can't mess up the Master Boot Record / Partition tables if you write carefully, ensuring you don't mess up the bytes after the first four-hundred-and-forty-whatever bytes which contain the bootstrap code. Link.

Yes, I see that, but it provided me with little in the way of actually inspiring me with ideas. Am I having issues of confidence ... what should I do, please help...

When Combuster tells you something, he's normally kind enough to provide links. The wiki is a great resource; not because it's the only place you can find the right information, but because the people who wrote it have read the specifications already, and they were kind enough to state the juicy stuff, and leave out the whole bunch of technical garble that litters specification documents to rampantly. Make the wiki your homepage if necessary, but be sure to give it a read.

Also, I'm not too sure if we could tell you whether or not you're having a confidence problem through a screen, by the way.

I'd like to impress upon you the idea that you should instead take about three weeks off and simply google feverishly, and READ. You also show symptoms of having not read the Intel Manuals. Google them up. Delve into them.

[XeonX369]

gravaera,

Thanks for you're reply. I do believe that your statement of me not having done my reading is correct. I find myself, always with new projects, being the type of person who jumps right in, being to enthusiastic, and not doing my research before-hand. I find that one I immerse myself and come across what I hadn't read about, I end up getting more excited because of the possibilities that I imagine.

I will indeed look up the Intel Manuals, but the thing is, I am being pressured by outside forces to do this project. The fact is that I am doing this as part of a High School Independent Study and that, even though I do get to set the pace, I feel like I must produce something on a grand scale to impress the "supervisors" who don't think that implementing Paging and a comprehensive Task Handler is that big of a deal for a beginner, because Micro$oft Window$ already has these set up.

I am starting to get the feeling that having this as an actual class wasn't as good of an idea as I had thought.

Thanks of all rendered assistance, you have inspired me to continue on my work.

[XeonX369]

Sorry for another post,

but I just would like to clarify what my disk problem is. Whenever I write my 512 byte bootsector to the first sector of my Disk (USB Flash-drive) I end up not being able to mount it, even if I specify the FS type. As far as my (relatively uneducated) understanding goes, I need to be able to mount it to place the second stage of the Bootloader into, so that my First Stage (in the bootsector) will be able to read from it, and then boot the Kernel.

I truely have done all of my research with this, browsing through countless pages, with all sorts of different suggestions being given, yet none work out.

I feel that this forum is where the true gurus reside, and so I seek an answer.

the way that I copy my bootsector to my disk is as follows:

dd if=[input_file] of=[output_file] bs=512 count=1

Am I missing anything, please, what am I doing wrong.

[kubeos]

Does your bootsector contain a partition table for the usb drive? You can't mount a drive without a partition table because the file system drivers first look up the partition entry that you are trying to mount, then read the bootsector from the first sector of that partition.

Eg. mount /dev/usba1 /mnt/somedir [pretend usba1 is your first partition of the usb drive]

The fs drivers look for the partition table entry for the first partition (which is located in the very first sector of the usb drive).
Once the driver knows where the first sector of the first partition is, it loads a bootsector from that sector. From the information contained in that bootsector it can figure out what type of filesystem is in that first partition, although some drivers can get some of this information from the partition table entry, they still need to read the first sector of a particular partition in order to get an idea of the layout of the file system.

So in the very first sector of your usb drive is a table of four entries (Called a partition table). The first entry points to the first sector of the first partition. In that first sector is where you want your boot sector. If you want that first partition to be able to boot, it will need to be set as active in the partition table.

I'm sorry if my explanation is a little unclear.. but maybe you can get some idea from it.

[kubeos]

If you switch to GRUB then a LOT of problems would be made much simpler. GRUB would be able to understand just about any file system that your system can format a partition to. You could format /dev/usba1, install grub to that partition, then just cp /mykernel/kernel /mnt/usb/kernel.bin, make a "menu.lst" pointing to your kernel.. and away you go.

[XeonX369]

Don't get me wrong, I love GRUB and use it everyday with my main computer,

but I really want to have this particular USB disk contain my own version of a bootsector.

I believe that I understand where you are going with your explanation, but if you will please clarify based upon the following:

I should place my bootsector in the First Sector of the First Partition and mark that as active, not in the First sector of the Device itself.

In other words, say that /dev/sdb is the device ... I should write the bootsector to the first 512 bytes of /dev/sdb1, instead of /dev/sdb like I was doing in the past. Is this correct?

Your help is essential, and I thank you very much.

[~]

In such cases you could very well alter each boot sector for it to write something dummy to the screen (each "boot sector" with a different value to know which is which when executed) and then write it back to the boot device in its corresponding position, then test in several computers to see which boot sector gets executed.

Based on that, you can know which you should use.

[kubeos]

Yeah, write your bootsector to /dev/sdb1, that is the first partition. Then just make sure in the partition table (located at /dev/sdb) that the first partition is active.

Out of curiosity, what file system does your boot sector use?