Can some outline how some of this works.
i have compiled a simple kernel in the multi boot format and boots. With help from several tutorials. How do I create a process that runs on my development OS. A process ,
. for example that adds two numbers and prints to the screen
What binary format is the process in ?
How do I compile it on my development machine.
How do I load it ?
Running Process
-
bluecode
Re:Running Process
May I ask how far you are and could you outline what you want (with[out] paging, loading from [floppy]disk or just multiboot modules)...
Do already have a runing memory management system for your kernel with[out] paging support? Do you already have some interrupt handlers? Do you want cooperative/preemtive multitasking?...
Loading processes is something that already needs a lot of framework...
Do already have a runing memory management system for your kernel with[out] paging support? Do you already have some interrupt handlers? Do you want cooperative/preemtive multitasking?...
Loading processes is something that already needs a lot of framework...
-
proxy
Re:Running Process
ok, well first of all, we need to clear up some definitions since some people define them slightly differently. Here's mine:
Process: This defines an address space and some basic accounting of things, such as open files, and such. A process can own zero or more threads.
Thread: This is a stream of execution and is owned by a process. In it's simplest form, it is just a context, and a state. Usually you will want to have these be able to block (temporarily stop execution) and unblock.
Scheduler: Picks next thread to run, plain and simple. Often invoked by a timer interrupt for premptive multitasking.
First of all, my personal recomendation is to try creating kernel threads first since it will let you jump right to a scheduler and all that.
Ok, so that's my personal definitions, note that my "process" does not give you a functional application alone.
So onto running a program, from here on I'll refer to what you consider a process a program since our definitions for process are slightly different.
To answer the "what format" question, the answer is any, it's up to you and you alone. Personally i chose ELF since I develop in Linux and my compiler/linker of choice creates ELF files by default.
So first we need to load the binary into memory. This can be done for you with multiboot modules or on your own. multiboot modules are a bit of a "temporary solution" as far as applications go since you will want to load them off disk in the future anyway most likely, so we'll go with manual for now.
This means we need two things, a way to read the file and a place to put it. So you will need to implement some sort of basic file system which your kernel can access, it can be actually linked into the kernel as an array at first if you want to skip disk drivers for now, or you can make a disk driver, once again up to you.
Once you can read a file, you will need to allocate space for your process and setup the proper address space information. For me this means allocate a new Process, I use paging, so this implies allocating a page directory at the least.
Next you want to load the binaries code into the processes address space, if you use paging like me, you will need to update the page tables and page table entries in the page directory to add new pages where the code will be located.
For now we will assume static binaries since it makes things more complicated once you allow libraries. We need to now copy the code into the process we setup. Note, you must parse the binary properly and find out at which address it should be loaded. If you want to have user space applications, this can be a pain, since you need to do one of two things: temporarily map the target pages into the current process, or temporarily switch to the new process, map the pages, and switch back.
Finally, we create a Thread object and set it's instruction pointer to the entry point of the application. This can be found by once again parsing the binary header (some formats, the entry point is simply the start of the image).
And there you have it, a "program" in a nutshell, there is much which needs fleshing out, i tried to keep it general.
I think you should start out with simple threads which all run in the same address space (the kernels), this will let you get a multitasking envrionment going. Then you should make syncronization primitives such as semaphores, mutexes, monitors, or whatever you decide you need.
After all that is done, then you should start thinking about processes.
proxy
Process: This defines an address space and some basic accounting of things, such as open files, and such. A process can own zero or more threads.
Thread: This is a stream of execution and is owned by a process. In it's simplest form, it is just a context, and a state. Usually you will want to have these be able to block (temporarily stop execution) and unblock.
Scheduler: Picks next thread to run, plain and simple. Often invoked by a timer interrupt for premptive multitasking.
First of all, my personal recomendation is to try creating kernel threads first since it will let you jump right to a scheduler and all that.
Ok, so that's my personal definitions, note that my "process" does not give you a functional application alone.
So onto running a program, from here on I'll refer to what you consider a process a program since our definitions for process are slightly different.
To answer the "what format" question, the answer is any, it's up to you and you alone. Personally i chose ELF since I develop in Linux and my compiler/linker of choice creates ELF files by default.
So first we need to load the binary into memory. This can be done for you with multiboot modules or on your own. multiboot modules are a bit of a "temporary solution" as far as applications go since you will want to load them off disk in the future anyway most likely, so we'll go with manual for now.
This means we need two things, a way to read the file and a place to put it. So you will need to implement some sort of basic file system which your kernel can access, it can be actually linked into the kernel as an array at first if you want to skip disk drivers for now, or you can make a disk driver, once again up to you.
Once you can read a file, you will need to allocate space for your process and setup the proper address space information. For me this means allocate a new Process, I use paging, so this implies allocating a page directory at the least.
Next you want to load the binaries code into the processes address space, if you use paging like me, you will need to update the page tables and page table entries in the page directory to add new pages where the code will be located.
For now we will assume static binaries since it makes things more complicated once you allow libraries. We need to now copy the code into the process we setup. Note, you must parse the binary properly and find out at which address it should be loaded. If you want to have user space applications, this can be a pain, since you need to do one of two things: temporarily map the target pages into the current process, or temporarily switch to the new process, map the pages, and switch back.
Finally, we create a Thread object and set it's instruction pointer to the entry point of the application. This can be found by once again parsing the binary header (some formats, the entry point is simply the start of the image).
And there you have it, a "program" in a nutshell, there is much which needs fleshing out, i tried to keep it general.
I think you should start out with simple threads which all run in the same address space (the kernels), this will let you get a multitasking envrionment going. Then you should make syncronization primitives such as semaphores, mutexes, monitors, or whatever you decide you need.
After all that is done, then you should start thinking about processes.
proxy