Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

System Calls: Understanding Operating System Interactions with Applications, Study notes of Electrical and Electronics Engineering

Clemson UniversityElectrical and Electronics Engineering

An overview of system calls, their role in operating systems, and how they differ from library functions. It covers common system calls related to file i/o, process control, memory management, time management, and interprocess communication. The document also discusses the differences between system calls and library functions, their impact on performance, and how to access their man pages.

Typology: Study notes

Pre 2010

Uploaded on 07/28/2009

koofers-user-lhg
koofers-user-lhg 🇺🇸

3

(2)

9 documents

1 / 3

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
ECE 222 System Programming Concepts
Lecture notes – System Calls
An operating system (O/S) is a program with two jobs: it manages the resources of the
computer (peripherals, files, memory, etc.) and it manages all other programs running on
the computer.
O/S
(kernel)
printer files memory
application
(program) application
(program)
application
(program)
resources of computer
system calls
The programs we write access the resources of the computer by calling functions
executed by the kernel. These functions are called system calls. A collection of system
calls is sometimes referred to as an application program interface (API).
There are dozens of system calls supported by any linux or unix kernel. Some common
examples include (none of these lists is all-inclusive):
• file I/O: open(), read(), write(), close(), creat() (yes there is no e – this is not a
typo), lseek(), link(). These system calls ask the O/S to access a file.
• process control: fork(), execl(), execv(), wait(), system(). These system calls ask
the O/S to run another program, or control how it runs.
• memory management: mmap(), brk(). These system calls ask the O/S to provide
memory to be used by the application program.
• time management: time(), setitimer(), settimeofday(), alarm(). These system
calls ask the O/S to access the system clock, in some cases taking an action that
affects a program when a given time interval has passed.
• interprocess communication (IPC): signal(), pause(), kill(), sigaction(). These
system calls ask the O/S to send a message to a program. For most of these
system calls, the messages usually originate in the kernel. Although they can be
used to send messages from one application program to another, there are more
advanced system calls better suited for this job.
pf3

Partial preview of the text

Download System Calls: Understanding Operating System Interactions with Applications and more Study notes Electrical and Electronics Engineering in PDF only on Docsity!

ECE 222 System Programming Concepts

Lecture notes – System Calls

An operating system (O/S) is a program with two jobs: it manages the resources of the computer (peripherals, files, memory, etc.) and it manages all other programs running on the computer.

O/S

(kernel)

printer memory files

application (program)

application (program)

application (program)

resources of computer

system calls

The programs we write access the resources of the computer by calling functions executed by the kernel. These functions are called system calls. A collection of system calls is sometimes referred to as an application program interface (API).

There are dozens of system calls supported by any linux or unix kernel. Some common examples include (none of these lists is all-inclusive):

  • file I/O: open(), read(), write(), close(), creat() (yes there is no e – this is not a typo), lseek(), link(). These system calls ask the O/S to access a file.
  • process control: fork(), execl(), execv(), wait(), system(). These system calls ask the O/S to run another program, or control how it runs.
  • memory management: mmap(), brk(). These system calls ask the O/S to provide memory to be used by the application program.
  • time management: time(), setitimer(), settimeofday(), alarm(). These system calls ask the O/S to access the system clock, in some cases taking an action that affects a program when a given time interval has passed.
  • interprocess communication (IPC): signal(), pause(), kill(), sigaction(). These system calls ask the O/S to send a message to a program. For most of these system calls, the messages usually originate in the kernel. Although they can be used to send messages from one application program to another, there are more advanced system calls better suited for this job.

Other system calls include those used for message passing, shared memory, semaphores, thread management, and network management (sockets). All of these are beyond the scope of this course, and are typically covered in a full operating systems class.

Note that we have already seen some of these system calls. Others look a lot like other functions we have already seen. For example, what is the difference between open() and fopen(), or read() and fread()? The former are system calls, meaning the code executed is part of the kernel. The latter are C standard library calls. The code for them is sitting in /usr/lib/libc.a, where we have already seen the code for printf() and other functions. The calling of those functions is handled differently. If a library is linked statically, then the code is already part of the running program, and is executed directly. If a library is linked dynamically, then the kernel handles it (the details beyond the scope of this class).

For most programs, the differences between system calls and library calls are moot. However, when coding for device drivers or other low-level operations, or for serious applications, the differences can become very important:

  1. Standard library functions are built on top of system calls. For example, the malloc() and related functions are built on top of the mmap() and brk() functions, meaning they call them to get the job done. The malloc() function is in the C standard library, while mmap() is a system call. This means that greater control over the computer’s resources can be obtained through system calls.
  2. Standard library functions tend to be more standardized than system calls. They both have standards bodies: the ANSI group defines library standards, while the POSIX group defines system call standards. However, since system calls provide direct access to the kernel, different O/S’s (including different variations of unix/linux) will have at least slightly different system calls.
  3. System calls cause a “context switch”, meaning that the application program stops while the kernel program runs for a while to perform the requested operation. Because of this, a system function call takes longer than a normal function call within your own program. Standard library calls often optimize operations to minimize the number of system calls, thus speeding up program execution.

As an example of the latter, consider again the open()/read()/write()/close versus fopen()/fread()/fwrite()/fclose() function calls. The former are system calls, while the latter are C standard library function calls. The latter are more efficient, because they use buffering. When an fread() call is made, more than the requested amount is read() from the file. The extra bytes are held in a buffer, local to the C standard library, and not directly accessible by your program. When your program next calls fread(), it may be able to satisfy the request using bytes already in its buffer, eliminating the need for another read() system call.

The man pages for system calls are stored in a separate folder than the man pages for library calls, and both are stored separate from system programs:

man 2 stat [provides man page for system call stat()]