1

So I know that a system call (e.g. open, close, read, write etc.) changes the mode bit twice - from user mode to kernel mode to serve the system call request and then back to user mode once it's done.

But if we have for example

int a = open("lol.txt", O_RDONLY);

the mode bit will change twice again to serve the open system call, but what about when it assigns it to a variable? Assuming it needs to store the variable into memory, do we have to go back to kernel to serve that request again? i.e. does the mode bit change 2 or 4 times in the above line?

sparta123
  • 83
  • 7
  • possible duplicate of [What are the calling conventions for UNIX & Linux system calls on x86-64](http://stackoverflow.com/questions/2535989/what-are-the-calling-conventions-for-unix-linux-system-calls-on-x86-64) – xmojmr Feb 22 '15 at 11:10
  • @xmojmr if you read the question, you'll realise it's not. – sparta123 Feb 22 '15 at 12:47
  • I believe the answer lies in the [ABI](http://en.wikipedia.org/wiki/Application_binary_interface) and it would become clear if you'd use your compiler's option to generate assembly source file output. The answer is **no** and the reason is that the system call returns all it has to do back to the user mode through registers and direct memory writes. Shuffling with variables (local, global, volatile, whatever..) is completely out of the scope of the system call. The `ABI` specifies what will be used as input/output channels and local variables are not on the list – xmojmr Feb 22 '15 at 13:11
  • @xmojmr I know it's outside the scope of the system call but the variable is stored somewhere in memory - and for this to happen, we have to switch into kernel mode, or at least that's my assumption. So that's my question - once we've opened the file and we're trying to save it to some variable, do we need to go back into kernel mode? – sparta123 Feb 22 '15 at 19:29
  • file handle in your example is an `int`. It comes back from the kernel in one register. Then this simple value can be saved anywhere you want using normal "_int b = a_" `C` instruction. It's single [MOV](http://www.tutorialspoint.com/assembly_programming/assembly_addressing_modes.htm) assembly instruction. No kernel mode is needed to perform this sort of things. Can you provide a more complex (or more practical) example of where you think some switching to kernel and back might be an issue? – xmojmr Feb 22 '15 at 19:56

1 Answers1

3

At the risk of gross oversimplification, the only ways to enter kernel mode are though an exception (trap or fault) or an interrupt.

For system call, application needs to trigger a trap. Invariably, the system call has is a wrapper function that possibly does some validation, loads the parameters into the appropriate register (maybe set up a stack from). Then it executes an instruction that causes a trap

     TRAP   #100 ; call the 100th exception handler

After that, the processor enters kernel mode. There is will validate the parameters then execute the kernel service. At completion it will return using an insertion along the lines of this:

   REI ; return from exception or interrupt

The the processor goes back to user mode.

open () may or may not be an actual system service. That is, one of the wrappers I just described. That depends upon the system. It is possible that open () could be a library function that calls multiple system services, in which case the processor would go into kernel mode and back multiple times.

If open () is a system service, the you probably go into kernel mode and back just once.

The open function, regardless of whether it is a system service or not, will invariably return the value in a register. Storing the value is a simple move instruction.

user3344003
  • 20,574
  • 3
  • 26
  • 62