I wanted to know is there any reason to minimize use of system call in code and what is the alternate of not using system call ,one would say use API but api in turns use system call
Is it True??
Because most system calls have an inherent overhead. A system call is a means of tapping into the kernel, a controlled gateway towards obtaining some service.
When performing a system call, some actions are taken (warning, it's a simplification):
You invoke a library (wrapper) function
The function puts the arguments where they are expected. Also the function puts the number of the system call in eax
The function calls a trap (int 0x80 or whatever)
The processor is switched to kernel mode
The kernel invokes some system_call routine
The registers are saved onto the kernel stack
The arguments are checked to be valid
The action is performed
The registers are restored from the kernel stack
The processor is returned to user mode
The function (finally...) returns
And I probably forgot some of the steps. Doesn't this sound like a lot of work ? All you wanted is the bold part. The rest is overhead.
A system call requires that the system switches from User mode to Kernel mode. This makes system calls expensive.
An article to understand this better:
Understanding User and Kernel Mode - Jeff Atwood
First, if you use framework or APIs (e.g. by using wxWidgets instead of rendering the windows manually, or the GNU C library) your code is portable between different operating systems.
Second, you if you're using APIs you won't have problems if the manufacturer changes how the operating system works under the hood, as the APIs (should) be the same as before.
The only reason that cames to my mind right now is portability issues. If you use system calls, your code will only run on that Operating System. And if you need to compile the same source to another OS, you will be in trouble, the API may be completely different.
Related
I'm new to RISC-V and operating system developing, and I'm now trying to make a simple hypervisor-like interface in RISC-V. What stops me right now is that I have no idea about how to trigger a machine call (like RISC-SBI) which stands in firmware level and machine-mode for a user-mode applications? Since recently user-level applications communicate with kernel by system calls. However I may have to make the call skip the kernel and directly to the firmware. How to achieve this for a high-levl application?
I' really in a difficult time. So much thanks for your replies.
To make a system call, load register a0 with which call you want to make (and possibly arguments to the syscall in other registers), then execute an ecall instruction with 01 in func3, which specifies Supervisor mode. To return to user mode after executing the system call code, the OS kernel executes an sret instruction, which returns to User mode from Supervisor mode. This is documented in the Privileged Architecture specification, but I'll admit it requires a bit of knowledge ahead of time to figure out where to look.
I am new to Operating system subject. And I am having trouble in understanding system calls interface. If you could help, I will be thankful.
thanks
I have tried to simply explain the whole process of making a system call.
The kernel provides a set of interfaces by which processes running in user-space can interact with the system. These interfaces give applications controlled access to hardware, a mechanism with which to create new processes and communicate with existing ones, and the capability to request other operating system resources.
These APIs (Application Programming Interfaces) act as the messengers between applications and the kernel, the applications issues various requests and the kernel fulfills them (or returns an error).
System calls provide a layer between the hardware and user-space processes.
But System calls and APIs are not the same thing.
APIs basically are function definitions that specify "how to obtain a specific service".
You generally don't make system calls directly, instead you use an API.
Each system call has a corresponding Wrapping routine, that specifies the API that the application program must use to invoke that system call.
(Wrapper Routines are function definitions whose only purpose is to issue a system call).
However, an API does not have to correspond to a system call, an API can offer its services directly in User mode, without making any system calls, or a single API function can make several different system calls, more so different API functions can invoke the same system call.
An API defines a set of programming interfaces used by applications. Those interfaces can be implemented as a system call, implemented through multiple system calls, or implemented without the use of system calls at all. The same API can exist on multiple systems and provide the same interface to applications while the implementation of the API itself can differ greatly from system to system.
From the programmer's perspective, the distinction b/w API and System call is irrelevant, to them its just another function call all he/she needs to think about is the function name, parameter type and return values. From the kernel designer's point of view the distinction obviously is very significant.
Further, when a User Mode process invokes a system call, the CPU switches to Kernel Mode and starts the execution of a Kernel Function(which happens to be a assembly language function) called the System Call Handler. This System Call Handler has a similar structure to that of other "Exception Handlers".
This System Call Handler first saves the content of the registers in the kernel mode stack.
Then based on the system call number (each system call has a number associated with it and the user mode process must pass this number as a parameter so that the requested call can be identified) the System Call Handler calls the relevant System Call Service Routine which in Linux happens to be a C function that actually goes on to implement the functionality requested by the User Process.
After that's done, registers are loaded back to their previous values and the CPU switches back to User Mode.
The same process can also be represented in a different manner.
A system call interface is a set of functions for requesting a service from the kernel on the operating system they are executed on.It provides an essential interface between the process and the operating system.
For example:
open();
Is a system call used to provide access to a file in a file system and so on.
The question says it all. When I say interface, I mean what the user interacts with completely. I've got an extensive C background and know enough to make a rudimentary OS but I'd rather not reinvent the OS. Using a linux build (or something else if better) such as Arch I'd like to know the most appropriate and extensive way to be the lowest layer over the OS.
The closest example I can think of to what I'd like is how Android Phones have perfectly usable interfaces with user permissions handled by the OS but it's a modified linux kernel. Is modifying the kernel the best way to go about it, and if so any pointers to setting up any sort of visual system such as OpenGL.
On most systems, one accesses the operating system by triggering an exception of some kind. Usually a processor has some kind of "trigger an exception that calls a system service" instruction. Each system service is identified by a number and that number is passed as either an operating to the exception or as a register value (depending upon the processor).
The normal practice is to have a wrapper function for each system service designed to be called from some high level language. The wrapper unpacks the parameters (usually on the stack) and sets up the hardware registers using those parameters. Then it triggers the exception to invoke the system service. This causes to processor to enter a protected mode and execute the system service. When the system service completes, the wrapper extracts the return values from hardware registers, then packs the result in to the return parameters for the caller.
In the Sparc V8 architecture we have some N register windows. Generally an RTOS during context switching pushes and pops registers. Is it possible( or already has been done) to use each of these register windows as one of the thread. This will make switching onto next thread as good as shifting register window and pushing and popping PSR ! Thus saving context switching time and enabling faster context switching frequency.
Maybe, it depends on what you mean by threads and how many.
The register windows are built around the idea of function calls and returns, implementing this in hardware and software traps with well defined operation. If your threads are just functions that get called in a round robin fashion etc... then yes they will get switched in this manner as will any other functions called from your "thread". That said once your have more functions than the number of register windows they will start getting paged in and out of the register file.
From the perspective of OS and User code... you don't have control of what happens when you enter and leave a register window as that is implemented as a trap as I understand it probably in the firmware. If you go changing how that works you aren't running a Sparc anymore because what it does there is defined in the Spec.
The whole point of Register windows has always been fast context switching.. but other aspects of Sparc hardware such as the TLB can get in the way of that... in the context of a Sparc MCU with a flat address space... then yeah it would be really fast.
I'm writing some code that is going to run under an hypervisor which only allows open, read, write and close syscalls to the external world.
Since part of the code is dependant on the platform it is being run on, I'd like to be able to automatically choose the appropriate code-path at runtime.
What is the most robust way of detecting the operating system using only these syscalls? I'm primarily interested in detecting windows and linux, but osx would be useful too.
uname watches for /proc/sys/kernel/ostype, you could use that.
For windows, it's worse. In theory, you should have C:\windows\system32\kernel32.dll. The problem is, however, that windows installation root is not required to be 'C:\' (although it's very common) - so i highly doubt ordinary open() could be considered reliable.