tag:blogger.com,1999:blog-5313249829740971301.post2713317857488145672..comments2013-07-07T12:44:26.122+05:30Comments on Vishy Ranganath's Minix Blog: kernel/proc.c - sys_call() internalsVishy Ranganathhttp://www.blogger.com/profile/11357138041307857124noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-5313249829740971301.post-29085473095563780072012-04-17T19:34:27.263+05:302012-04-17T19:34:27.263+05:30Thanks very much for replying. That clarifies my d...Thanks very much for replying. That clarifies my doubts.Harithahttps://www.blogger.com/profile/05827301515899301725noreply@blogger.comtag:blogger.com,1999:blog-5313249829740971301.post-24389801128898848312012-04-16T23:38:43.747+05:302012-04-16T23:38:43.747+05:30Haritha,
Sorry about the delay. The processes in ...Haritha,<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.Vishy Ranganathhttps://www.blogger.com/profile/11357138041307857124noreply@blogger.comtag:blogger.com,1999:blog-5313249829740971301.post-52148095773839383832012-04-02T09:39:18.706+05:302012-04-02T09:39:18.706+05:30I'll get back to you. Please give me some time...I'll get back to you. Please give me some time.Vishy Ranganathhttps://www.blogger.com/profile/11357138041307857124noreply@blogger.comtag:blogger.com,1999:blog-5313249829740971301.post-13026198109366195982012-03-31T11:53:32.818+05:302012-03-31T11:53:32.818+05:30I have been reading about MINIX drivers and I have...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?Harithahttps://www.blogger.com/profile/05827301515899301725noreply@blogger.com