System call parameters
-
Ozguxxx
System call parameters
Hi, I am trying to set up system call basics and I am wondering how people do system call parameter passing to kernel. I am approaching user space in a way that user might pass parameters that are necessarily not in kernel address space I mean not all of user address space is shared by kernel, so I think I will have to copy parameters into kernel address space, but in that case I will have to have some shared memory (like one page) between each user process and kernel, is that a good approach? I mean do you think it is efficient?
Re:System call parameters
Hm... am I mistaken or can the kernel always access all of user space?
Every good solution is obvious once you've found it.
-
Ozguxxx
Re:System call parameters
Well, ok, kernel can always access the user address space but the problem is that kernel and user have different page directories and also I do not map all of the user space into kernel space and Im looking for a solution without doing this. I mean to be more specific I am not mapping user heap space into kernel address space (that might be theoretically wrong, which is what Im trying to understand) so for example user calls a printf and passes a string that is in its own address space but since kernel cannot see this string, we have to copy it into a shared memory in while handling system call. Is that efficient? I hope I am clear now. Thanx.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:System call parameters
hmm, it's kinda unusual to give the kernel a dedicated address space -- just for the reason you're evoking ... What is traditionnally done (i mean in Un*x, Windows, etc.) is that the kernel occupy a portion of the address space (traditionnally 0xc0000000 .. 0xffffffff) and the user program stands in the rest of the address space.
The terms 'user space' and 'kernel space' used in Linux sources are not to be taken as "user address space" and "kernel address space" ... the 'kernel space' is a portion of *every* process (i.e. the kernel is mapped in every address space)
Things are a bit different in microkernels where only the microkernel is mapped that way and the services are in separate address space, which indeed means that if you want to deliver bytes to a process, you must 'flatten' them first so that the microkernel can pass them in one chunk to the other process ...
In Component programming frameworks based on RPC (like COM, CORBA, JAVA-RPC, etc), the 'flattening' process is called 'marshalling' and is deferred to the user process through automatically-generated proxy/stub functions.
The terms 'user space' and 'kernel space' used in Linux sources are not to be taken as "user address space" and "kernel address space" ... the 'kernel space' is a portion of *every* process (i.e. the kernel is mapped in every address space)
Things are a bit different in microkernels where only the microkernel is mapped that way and the services are in separate address space, which indeed means that if you want to deliver bytes to a process, you must 'flatten' them first so that the microkernel can pass them in one chunk to the other process ...
In Component programming frameworks based on RPC (like COM, CORBA, JAVA-RPC, etc), the 'flattening' process is called 'marshalling' and is deferred to the user process through automatically-generated proxy/stub functions.
-
Ozguxxx
Re:System call parameters
Well, I did not do a very big thinking I mean I just made a decision if everything was ok; In technical terms if every line of code worked as I thought. I am now trying to get theoretical things right... Anyway I am currently doing like: kernel works at 0xc0000000-... and user is mapped onto 0xc0400000-0xc0800000(No real important reason). I am meaning kernel address space by kernel space and user address space bu user space. I dont know about unix manuals. I also dont know about corba, java-rpc, etc. Do you think my approach is efficient?
-
nullify
Re:System call parameters
Suppose the user process wished to perform a non-blocking write to a network controller. The kernel could handle this by either one of:
1) Initiate the operation using a pointer to the user buffer. Return to user process.
2) Copy the user buffer to kernel space and initiate the operation with the kernel buffer. Return to user process.
The problem with option #1 is that kernel would have to signal the user when it has finished using the buffer so that the user process knows it is now free to re-use it. By duplicating the buffer in kernel space instead, such complications are eliminated.
For blocking operations, consider:
1) The user executes a blocking "write" system call.
2) The kernel stores a pointer to the user buffer and initiates the operation. The current process is marked as "blocked" and the kernel schedules a new process to run.
3) Now the kernel's buffer pointer is invalid, since it was pointing to the buffer in the original process' address space, but a new address space has been loaded into memory.
A workaround: when the device becomes ready to accept the next chunk of data from the buffer, temporarily switch back to the original process to make the buffer accessible again. However, process switches are expensive and this should be avoided if possible.
If the kernel had instead copied the buffer to kernel space, it would remain accessible regardless of a context switch on a blocking I/O syscall.
1) Initiate the operation using a pointer to the user buffer. Return to user process.
2) Copy the user buffer to kernel space and initiate the operation with the kernel buffer. Return to user process.
The problem with option #1 is that kernel would have to signal the user when it has finished using the buffer so that the user process knows it is now free to re-use it. By duplicating the buffer in kernel space instead, such complications are eliminated.
For blocking operations, consider:
1) The user executes a blocking "write" system call.
2) The kernel stores a pointer to the user buffer and initiates the operation. The current process is marked as "blocked" and the kernel schedules a new process to run.
3) Now the kernel's buffer pointer is invalid, since it was pointing to the buffer in the original process' address space, but a new address space has been loaded into memory.
A workaround: when the device becomes ready to accept the next chunk of data from the buffer, temporarily switch back to the original process to make the buffer accessible again. However, process switches are expensive and this should be avoided if possible.
If the kernel had instead copied the buffer to kernel space, it would remain accessible regardless of a context switch on a blocking I/O syscall.