I can now load programs!
To run the program, the os needs the 'symbol file' and the 'object file'. The object file is the .o file that the compiler makes (without any special flags or parameters, or anything else). The second file contains that address of all the symbols in the current kernel. This file needs to be updated when a new kernel is compiled. I wrote a program to make the symbol table from the kernel. It needs to be copied to the oskit filesystem before running other processes. Since the symbol file does not take advantage of the hashing function defined by the ELF file documentation (like the one shared libraries use), each symbol lookup needs to make an O(n) lookup where n is the number of symbols (about 4000).
The example programs I've run include the 'helloworld' program which writes a message to the screen 10 times and a 'cpuinfo' program which calls the oskit function to fill an array with x86-specific cpu information (like processor, model, stepping, feature-flags) and prints them to screen. These are just for proof of concept.
The loader does not yet support the bss section. I need to get the size of the bss section from the object file. There should not be anything difficult in adding this functionality, it just hasn't been done yet. There are also huge memory leaks since I lack a good way of tracking memory allocations.
I added some support for file transfer. For the os to download a program, it connects to the 'pfsd' server on a remote node (i.e., berg.crhc.uiuc.edu). It can then request to upload files. Any machine can get a file from the os through the httpd server. Both interfaces use an html interface format.
There are lots of things that could be cleaned up with the file system (like adding 'ls/dir' commands)
I found the way to set the PIT ( programmable interval timer ) for x86 processor via some assembly codes . I experimented this with two threads running the same bubble sorting algorithm on 20000 integers. For thead 1, when I schedule it, I always set the timer interrupt to be 50 hz and for thread 2, it's always set to 200 hz. Thread 1 finished much earlier than thread 2. The following lines shows the total clock cycles the two threads used to compute and used to wait to be scheduled
| tid | total_in | total_out |
| 1 | 2409963321 | 602048229 |
| 2 | 2414767559 | 2401981086 |
We can see thread 2 spent 4 times as many clock cycles waiting than thread 1.
I may opt to add 'console' thread, so that commands can be processed from the keyboard or from the net (like remote login). This should facilitate development time.
I can also look into what Lan has done and try to use his checkpointing code.
What's next from Jun:
I will integrate the real-time API I wrote before and to make them work.