Exercises

I’d write down my own answers, please point out my errors with no mercy.

Q1

When can a routine executing in the top half of the kernel be preempted? When can it be interrupted?

The top half of the kernel provides services to processes in response to system calls or traps. And the FreeBSD kernel is rarely preempted to run another user process while executing in the top half of the kernel.

But it still can be interrupted to run a real-time process or by interrupts from the bottom half of the kernel. Normally device-interrupt processes have a higher priority than user processes or processess running in the top half of the kernel.

Q2

Why are routines executing in the bottom half of the kernel precluded from using information located in the current user process?

The bottom half part of the kernel comprises routines that are invoked to handle hardware interrupts.

Activities in the bottom half of the kernel are synchronous with respect to the interrupt source but are asynchronous, with respect to the top half.

Software cannot depend on having a specific or any process running when an interrupt occurs. Thus the information located in the current user process may be not available.

Q3

Why does the system defer as much work as possible from high-priority interrupts to lower-priority software-interrupt processes?

To ensure that critical operations will not be blocked from executing longer than necessary.

Q4

What determines the shortest(nonzero) time period that a user process can request when setting a timer?

The clock interrupt rate determines the frequency of call to hardclock() routine, and hardclock() will make softclock() runnable if the latter needs to be run. softclock() routine is to arrange for the execution of periodic events, including process real-time timer.

Q5

How does the kernel determine the system call for which it has been invoked?

Syscall() is the appropriate handler of system call, and it takes a specific set of parameters, they are the system-call number and an exception frame.

Q6

How are initialized data represented in an executable file? How are uninitialized data represented in an executable file? Why are the representations different?

Initialized data are stored in executable-file disk image while uninitialized data are not in it, because they can be created on demand with zero-filled memory at runtime.

Q7

Describe how the ‘#!’ mechanism can be used to make programs that require emulation appears as though they were normal executables.

Files falling into the first classification have as their magic number(located in the first 2 bytes of the file) the two-character sequence #! followed by the pathname of the interpreter to be used. The image activator that will be selected is the one that handles the invocation of interpreters. It will load and run the named interpreter, passing the name of the file that is to be interpreted as an argument.

Q8

Describe the security implications of not zero filling the stack region at program startup.

Not zero filling the stack region at program startup means the current process can read data left by previously running programs, which may lead to critical information leak or surreptitious misuse of data.

Q9

Why is the conversion from UTC to local time done by user processes rather than in the kernel?

To keep kernel simple and fast as it doesn’t need local time to work properly.

Q10

What is the advantage of having the kernel rather than an application restart an interrupted system call?

Simplify application code as it doesn’t need to be aware of system-call restarting.

Save the overhead cost on entering the kernel.