Friday, November 12, 2010

kernel/proc.c - sys_call() internals

I gave some idea about sys_call() in the preceding diagrams. sys_call() does a number of checks before it allows a message or notification to be passed from one process to another. These are all part of the security mechanisms in the kernel that keep processes from doing things they are not allowed to do and from corrupting each other's memory maps. Assuming that a process has just made a system call, here is the list of checks that happen:

  1. Does the process have the privileges to make this particular system call? (the priv structure for this process in the process table is looked up to determine this)
  2. In the case of a 'send' or 'notify', is the destination a valid process? In the case of a 'receive' is the source a valid process? Note that a caller can specify 'ANY' as its source in which case it is looking for a message or notification from any process, so this check is unnecessary for that case. 'ECHO' is also a special case where this check doesn't make sense.
  3. Does the message pointer point to a valid region in memory i.e. is it really within the memory map limits of the calling process? Again, the memory map limits are available in the memmap struct for this process in the process table.
  4. If the request is to 'send' to some process, is the caller allowed to send to the destination process?
  5. Is the destination process running?
  6. Has system shutdown started?
If all the checks above have passed then call one of the following functions: mini_notify(), mini_receive() or mini_send() depending upon the nature of the request.

Refer to the 'Message Primitives and Process States' diagrams (preceding posts) for details on what happens within the above functions.

Comments welcome.

4 comments:

  1. I have been reading about MINIX drivers and I have this doubt: The authors call the drivers in execution as "tasks" and place them in 2nd layer. What kind of system calls do these tasks execute? At first, I thought they do not execute any system calls but get things done by calling procedures directly since they are linked to the kernel. But then again, they can block waiting for interrupts from device controllers. So I think they do use system calls (to do some receiving, perhaps..? I am not sure of anything.) And, what happens when a task is in blocked state (waiting for an interrupt from its respective controller) and file system process tries to request some thing from that task? Since the task is waiting on an interrupt and is not open to receiving messages from file system, will file system process be blocked? That means any process that wants to request some thing of the file system process is blocked?

    ReplyDelete
  2. Haritha,

    Sorry about the delay. The processes in Layer 2 are the drivers and as far as I know, they are not called anything else. The only 'tasks' are the 'System' task and the 'Clock' task.

    Your question is about the drivers. The drivers execute system calls just like any other process in layers 3 and 4. The system calls end up in calls to the messaging primitives which causes process state transitions and context switches.

    No, drivers cannot call kernel code directly. They have to rely on system calls and the messaging primitives (send, recv etc.). Only the System and Clock tasks can call kernel code directly. Remember that Layers 2, 3 and 4 are the user mode layers. Only Layer 1 is in kernel mode.

    You are right that the drivers can block waiting for inputs from devices. They will usually transition to the 'ready' state after an interrupt routine has run for the corresponding hardware interrupt.

    The answer to the last couple of questions in your message is yes. The file system process can be blocked and processes that want to talk to the file system can get blocked as a result. This is not so inconceivable. Multiple processes can block for IO since the IO device (hard disk or other) can be read only serially.

    ReplyDelete
  3. Thanks very much for replying. That clarifies my doubts.

    ReplyDelete