System call vs Function call

Question

What is the difference between a system call and a function call? Is fopen() a system call or a function call?

Sacrilege

Stackoverflow police is here ! This particular question seems valid. Have you considered the case of someone not taking a course, yet having this doubt? – Yoicks

And even if it was a homework question, research is about asking the right questions, he will have to distil all of the answers on this page into a correct answer. If he doesn't understand the content he will screw it up anyway. Nothing wrong with it imo. – Bashibazouk

Answer 1

A system call is a call into kernel code, typically performed by executing an interrupt. The interrupt causes the kernel to take over and perform the requested action, then hands control back to the application. This mode switching is the reason that system calls are slower to execute than an equivalent application-level function.

fopen is a function from the C library that, internally, performs one or more system calls. Generally, as a C programmer, you rarely need to use system calls because the C library wraps them for you.

Nighttime

This mode switching is the reason that system calls are slower to execute than an equivalent application-level function. This does not mean that fopen() is faster than performing the same operation using the relavant system call right? Because if fopen() is already performing system calls to do its job, then using the relavant system call must be, in the worst case, at the same speed with fopen() right? – Chorister

Right. fopen() might be ever so slightly slower than doing the system call yourself, but by using fopen() you gain portability, readability and maintainability. – Nighttime

Isn't caching and buffering the main reason why a function call is faster. I am really a beginner with limited knowledge. What are your thoughts about this ? – Christyna

@Christyna Yes, in case of calls like fwrite, buffering can make the C library calls faster than using system calls directly. In case of fopen this is not applicable though. – Nighttime

Answer 2

fopen is a function call.

A system call interacts with the underlying OS, which manages resources. Its orders of magnitud more expensive than a function call, because many steps have to be taken to preserve the state of the process that made the syscall.

On *nix systems, fopen wraps open, which makes the system call (open is the C - wrapper for the syscall). The same happens with fread /read, fwrite / write , etc..

Here there's a nice description of the tasks executed by a unix syscall.

Yoicks

It wraps open on *nix systems, but it wraps different system calls on other OSs (such as CreateFile on Windows). – Litha

Yes, I have something agains C or C++ running on windows, so I always fail to consider it. (completely dogmatic, I know) – Yoicks

That is ridiculous considering windows has as much C/C++ (considering professional CAD/office software and video games), if not more, software on it. Visual Studio isn't that bad either for C/C++. – Bashibazouk

@Hassan I know, i dont pretend to justify it, I just say I dont like it. – Yoicks

It's worth noting that on UNIX open() is a system call, whereas on Windows open() is a library function wrapping some native kernel interface, much like fopen(). – Bortman

Thanks for sharing that link to the course on *Nix calls, really nice overview. – Bipinnate

Answer 3

Actually, the system call is not related to function call. The only common of these two mechanism is that they both provides services to the caller.

• From view of thread execution to see system call:

  A system call is function for application mode program to request services provided by underline OS. The system call will bring the running thread from user mode into kernel mode, execute the system call handler function, then return back to user mode.

• Syscall Parameters:

  The parameter of a system call is (syscall number, params...). The meaning and format of params depends on syscall number.

• From view of syscall library provided to userland program:

  The user mode program usually calls glibc's library to call system call. For example, the open() function in glibc:

  1. put system call number SYS_OPEN in eax register
  2. request system call by calling a software interrupt or sys_enter instruction

Peisch

Answer 4

System call actually calls out to an API executed by the kernel space. With all the associated costs this assumes (see Wiki, or this link for details)

A function call is a call to a piece of code in user space.

However, please note that a function call MIGHT be to a function which in the process of its execution does system calls - "fopen" being one of such examples. So while the call to fopen itself is a call to a function, doesn't mean that the system call will not happen to handle the actual IO.

Globefish

Answer 5

A point of view to add to this discussion is that a function call generally in the most optimistic case has overhead of a a few 8-bit instructions (4-10 on average)in x86.

A system call has the following properties.

1. It Executes far more instructions, it has to freeze a process instead of simply the stack state.
2. The timing involved is mostly non-deterministic.
3. It is often a scheduling spot, and the scheduler may choose to reschedule.

For these three primitive reasons (there are probably more), one should reduce the amount of system calls where possible -- e.g., networked system software keeps socket handles (and other application specific internal data structures used by a connection) around to assign to new connection, why bother the kernel ?

Remember that software is built like a upside down pyramid. System calls are at the base.

Bashibazouk

Moreover Isn't the system call mapping virtual memory to physical memory? – Decoteau

Answer 6

If you're using Linux you can monitor system calls performed by an application via strace:

strace /path/to/app

Its output might give you a good insight on what's going on within libc, and which functions are actually system calls.

Malpighi

Answer 7

The question has excellent answers already, but I think I can add something (one segment from ostepthat isn't already in other answers

Sometimes system call and function call have the same signature, for example, open():

open()-system call

--- ~/Documents » man open(2)

OPEN(2)                 Linux Programmer's Manual           OPEN(2)

int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
...

open()-function call

$ man open(3)

--- ~/Documents » 
OPEN(3P)                        POSIX Programmer's Manual          OPEN(3P)
...

int open(const char *path, int oflag, ...);

...

Quoting form OSTEP

You may wonder why a call to a system call, such as open() or read(), looks exactly like a typical procedure call in C; that is, if it looks just like a procedure call, how does the system know it’s a system call, and do all the right stuff? The simple reason: it is a procedure call, but hidden inside that procedure call is the famous trap instruction. More specifically, when you call open() (for example), you are executing a procedure call into the C library. Therein, whether for open() or any of the other system calls provided, the library uses an agreed-upon calling convention with the kernel to put the arguments to open in well-known locations(e.g., on the stack, or in specific registers), puts the system-call number into a well-known location as well (again, onto the stack or a register), and then executes the aforementioned trap instruction. The code in the library after the trap unpacks return values and returns control to the program that issued the system call. Thus, the parts of the C library that make system calls are hand-coded in assembly, as they need to carefully follow convention in order to process arguments and return values correctly, as well as execute the hardware-specific trap instruction. And now you know why you personally don’t have to write assembly code to trap into an OS; somebody has already written that assembly for you.

Demo

Answer 8

fopen is a function call, but it may sometimes be referred to as a system call because it is ultimately handled by the "system" (the OS). fopen is built into the C runtime library.

Blondie

Answer 9

Just to complete the picture presented by the others, fopen is commonly implemented as a wrapper around open, which is also a user-accessible function. fopen is, in a sense, higher-level than open since the FILE* structure it returns encapsulates stuff for the user. Some users use open directly for special needs. Therefore it wouldn't be right to call fopen a "system call" in any way. Nor does it execute system calls directly, since open is also a function callable by the user.

Ranch

Answer 10

System call is executed at kernet level and not in user spce because it requires some prievilege to access the hardware.

Therfore when programming in user space and making some ordinary function call like fopen in C language the libc generally wrap this function to specific code code where an interrupt is generated to switch from user space to kernel space , then in kernel space the required system call to perform the functionality of the function call at hardware level will be executed in kernel space .

Torquay