[OSy] Fourth Extended Assignment

[Petr Tůma]

Hi Immo,

> 1. In a former mail we discussed the implementation of sys_exit and I
> thought i was meant to use thread_destroy in within the method.
> Actually there is no prototype in the thread.h file and it seems to
> be private due to that. Are went meant to add that prototype or is
> there another option but using thread_destroy?

After some thought, I believe it would be too much work to implement this feature properly. At the core of the problem is the fact that you cannot safely call thread_destroy in current Kalisto even if you exported it - the thread can still be queued in the scheduler or in some synchronization object and that object will eventually try to wake it up. A correct solution would therefore have to handle this problem, for example by adding a new return code to thread_wakeup and making sure all places that attempt to wake a zombie thread would perform appropriate cleanup.

Please just ignore the other threads in sys_exit, we'll have to tweak the assignment to avoid this issue for the future.

> 2. Within the kernelside syscall.c file is a method for handling the
> different systemcalls by checking a table. It contains a TODO-Tag. Do
> we have to care about that? If that is the case: What is a
> branch-delay-slot?

Ignore this TODO, it is for general Kalisto design and not for any student assignment.

To explain in detail, a branch delay slot is a feature of the MIPS CPU. In general, the processor designers have to decide what to do with the instruction processing pipeline when executing a conditional branch (jump) instruction. To fill the pipeline, the processor needs to know whether the jump condition will hold (if yes, the pipeline should be filled with instructions at the jump target address, if no, the pipeline should be filled with instructions following the jump). But the jump condition can sometimes only be evaluated just before the jump, which would invalidate the benefits of pipelining. The MIPS processor designers solved the problem by introducing what they call a branch delay slot - in effect, this means that one more instruction is executed after each jump:

1. SOME INSTRUCTIONS
2. BRANCH (JUMP) INSTRUCTION JUMPING TO X
3. NEXT INSTRUCTION IN BRANCH DELAY SLOT
4. SOME MORE INSTRUCTIONS
X. INSTRUCTIONS AT BRANCH TARGET

In the list above, the processor would execute 1, then 2, then 3, and then X (rather than 2 and then X as one would expect).

How does this impact syscalls ? The processor saves the location of the syscall instruction when executing it. If the syscall handler were to return to this address at the end of the syscall, it would immediately execute the syscall again - so the handler has to return to the next instruction. In the syscall handling code, you can see a line doing "registers->epc += 4", which is exactly this - moving the program counter register four bytes forward, that is, after the syscall instruction. The problem is, this does not work correctly if the syscall was in a branch delay slot, because if that were the case, the execution would need to proceed at the jump target instead. To avoid the need to handle this, the ABI requires that syscalls are not placed in branch delay slots.

> 3. The "tests-user.sh" script uses the scripts uspace1, uspace2,
> uspace3. At first I don't understand how they are connected to our
> specific Task. Besides printf() they dont run any of my Code. On top
> of that they uspace1 and uspace2 instantly throw exceptions, while
> uspace3 accesses an invalid memory address. Are they meant to be that
> way or did I miss something? Also they have weird behavior:

I do not think you missed anything. The coverage of the tests for userspace is quite poor, and they are meant to mostly check error conditions. Please do your own tests where you feel you need more testing, we will mostly use manual inspection to verify the assignment.

> 4. In my printf implementation I am using a buffer of fixed length,
> so the maximum amount of literals is limited at 2000. Does that meet
> the requirements?

If you check for the buffer overflow condition then this is fine.

Regards, Petr