OSDev.org

kind of am ambiguous question. let me clarify.

I'm writing a operating system that is completely command line (like MSDOS). and i need to have the kernel load a executable that does memory checking and setting . how would i go about loading the executable after the kernel has loaded? would it be easier to make the secondary executable a DLL/SYS file?

diagram:

post-> ixkrnl.exe -> ixmemmgnt.exe -> command_line

I had done this before for program execution:
My steps, also anyone may edit my list or optmize it
1]First I loaded the executable into memory
2]Created a new process and linked to the address where it is loaded(Jump to that address)
3]After the process returns a 0 then terminate

Also make sure you have enough security to prevent the system from crashing.if you are using paging, you need a Virtual Memory Manager to allocate the memory for the program as well as a physical memory manager.

LindusSystem wrote:I had done this before for program execution:

mhm

Tandex wrote: kind of am ambiguous question. let me clarify.

I'm writing a operating system that is completely command line (like MSDOS). and i need to have the kernel load a executable that does memory checking and setting . how would i go about loading the executable after the kernel has loaded? would it be easier to make the secondary executable a DLL/SYS file?

diagram:

post-> ixkrnl.exe -> ixmemmgnt.exe -> command_line

I am currently re-writing my MS-DOS copy. In simple terms (if you are going to MS-DOS single tasking way)


Allocate memory, load the file and process it by its file type (for example if its MZ read its header, if its COM just load it and make sure the offset (IP) 0x100 is the start of the program) Have a return interrupt set up (should be part of the OS API) for return or terminate but stay resident and have it return to an address either in the kernel or your command line interface.

or push the far return address onto the stack and have the program just retf at the end of execution. This is a real mode like concept example.

I do these to start a userland application:

process_create( const char* file, unsigned int priority, unsigned int quantum_per_run )

• allocate kernel stack (I use one kernel stack per thread)
• clone page directory (clonse kernel part and zero user part)
• initialize process structure with a thread control block that store the cpu context and a few variables used by scheduler
• store process specific information in a page, which include the executable name and environment
• add the process into scheduler's ready list

The TCB is specially crafted that the thread will resume to a stub function:
void process_stub ( PROCESS* process )

• map the process specific information
• load the application, I'm using ELF32/ELF64. The loader will load the application according to the LOAD segment specified in the executable, and do reloactions, pull in additional import, etc
• create a heap and a stack for application
• jump to application with ring3

Feel free to ask for detail in specific part.

My list:
1. create new thread (an empty address space with it's own TCB)
2. temporarily map it's paging structures to kernel memory
3. map executable from cache or map it from fs
4. look for main() in it, and set entry point as instruction pointer in TCB
5. look for external libraries and map them from cache or map them from fs
6. map environment
7. unmap paging structures
8. insert new TCB's address into one of priority queues (so it can be scheduled on next interrupt)
9. return thread id

After that you can communicate to the new thread by sending async and sync messages to the returned thread id. I also have a message->method call->acknowledge dispatcher that makes RPC fully transparent.

I allocate code memory in 2MiB units on x86_64 (moving only a PTE pointer around), and I don't use PML4 so I can skip two levels of the mapping hierarchy which is fast. My libraries and executables are all smaller than 1 unit, they fit perfectly (no problem with allocating more for one file).

turdus wrote:I allocate code memory in 2MiB units on x86_64 (moving only a PTE pointer around), and I don't use PML4 so I can skip two levels of the mapping hierarchy which is fast. My libraries and executables are all smaller than 1 unit, they fit perfectly (no problem with allocating more for one file).

Do application able to access more than 1G local address space? or you have any mechanism avoid one application interfere with other application?

bluemoon wrote:Do application able to access more than 1G local address space?

They can access 2^56 space. 512GiB of it is local.

or you have any mechanism avoid one application interfere with other application?

I change the first entry of PML4 on address space switch, and I reload the same base to CR3. Other entries serves as shared memory.