Hi, As far as I could understand your question, you are asking how a user space library function is blocked on the topmost system call kernel function. Actually when a user process library function (in your case socket) makes a system call, it executed "int 0x80" instruction, which actually switches the CPU mode from user to kernel mode (ring0 to ring3), at this time the stack is also changed from user stack to process specific kernel stack, the state of the user function is stored on the kernel stack, so that we can later on return back to user space, return address saved is the address of next instruction after "int 0x80" in user library function. Once we enter the kernel, system_call function is called, which in turn calls the appropriate "sys_" functions after checking the system call number passed by user process in processor register (in our case sys_socket). These "sys_" function actually implement the logic/functionality of service provided by that system call and the lower kernel functions called by this "sys_" function might put the process to sleep using kernel sleeping mechanisms like wait queues. For reading about wait queues, read the 5th chapter of LDD. -Gaurav --- jhoney jhoney <jhoney_joney@xxxxxxxxxxxxxx> wrote: > Hello All, > > I have one doubt. How the process is blocking on a > system call. For instance, I have one system call > like socket() from glibc. This library call is > going to call sys_socket() kernel function.My doubt > is how the fucntion socket in the > application(process) is waiting untill sys_socket > returns one file descriptor, and How the > sys_socketis returning the fd to a blocked call > socket. > > Regards > > Jhoney __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
