Basics of Operating Systems

This session is dedicated to the study of basic concepts of Operating Systems.

You don't need to submit source files or reports for this sessions. For this session, you will need to log into a PC running Linux. If you are at Eurecom, simply log on a PC of rooms 52 or 53.

Trick. In Linux, do you know that you can do a copy/paste very easily with your mouse only? Simply select some text with your mouse, then move your mouse pointer to the place where you want to copy this text, and then click on the middle mouse button ... the text is copied!

I. Basic and Chronology

1. Open the slides Introduction on Operating Systems


2. Watch the video on slides 1-13


3. Without reading the slides, are you able to cite the three main interests of Operating Systems?


4. Go to Slide 10. Place all elements of OS listed on the top left, red font, in the OS layers (down right).

II. Services

1. Open the slides Introduction on Operating Systems


2. Watch the video on slides 14-22


3. Type the following command. How do you explain the difference with the read() function of slide 20?

$ man write



4. Go to slide 22. For each category, find a syscall of your GNU/Linux Operating System.


5. Is malloc() a system call?

III. Kernel architecture

1. Open the slides Introduction on Operating Systems


2. Watch the video from slides 23 until the end


3. Find the page related to "Windows NT" on Wikipedia, and figure out in which programming languages Windows is programmed. Do you know why those languages were used to program Windows? Do you think this is the same for other common Operating Systems?

IV. First experiments with GNU/Linux

1. You are currently logged on a GNU/Linux PC. Run the following command to verify this:

$ uname -a

What other information can you gather by running this command? Use the $man uname command if necessary, and explain the information that you can learn about your Linux kernel. In particular, which option makes it possible to print only the operating system's version?


2. Sources of a Linux Kernel can be accessed downloaded from kernel.org
Kernel sources can be compiled. That compilation generates an executable file which is a Linux kernel: this kernel can be executed when the computer starts.

First create a new directory - name it as you like e.g., "foo2023" - in which you will copy the source files: (/home/Local_Data applies only to Eurecom PCs)

$ cd /home/Local_Data/
$ mkdir foo2023
$ cd foo2023
$ cp "path-to-downloaded-kernel" .



3. By the way, is /home/Local_Data a directory located on your PC, or on a server? (Explain how you can confirm this)
(Help me!) Try to use the "df" command



4. Now, uncompress and untar the Linux source files into your new directory with (replace "linux-6.0.tar.xz" with your kernel version):

$ tar -xJf linux-6.0.tar.xz



5. Do you know the difference between the "z" compression and the one with "tar"? Why are the two useful?
(Help me!) Execute "man tar" and read the beginning of the "DESCRIPTION" section



6. Quickly browse the first level of the various directories. Do you understand how files are organized? Use the README file located in the main directory to get a better understanding of the source file organization.


7. Launch kernel compilation (instructions are provided in the README file provided e.g. in Documentation/admin-guide): the compilation process may fail for different reasons, or it may take a long time (10 minutes or much more: in that case, you can start the next exercise while the compilation goes on) before your obtain a kernel. In case the compilation fails, don't worry: the idea is not to obtain a new kernel, but just to figure out how a new kernel could be built.
   Imagine that the compilation process succeeds: what would you have to do to be able to use that new kernel at startup? Why isn't possible on Eurecom PCs, and do you know which protections are used to prevent this?
(Help me!) (Partial answer) You would need to change the kernel that is executed at startup ... you have to be root to do this)

V. Using System calls

This exercise might be a bit more difficult for students not at ease with C programming, therefore you are not expected to complete it during this session, but probably to finish it later (homework). Also, do not hesitate to ask for help! A good understanding of basic concepts of C is needed to do well in this course. You will need it for lectures, labs, project and exam. So if you have trouble doing the following exercise, spend 30 minutes reading any good C tutorial you can find, e.g. this one or this one.

Depending on your background, a tutorial on bash linux commands -- especially the part on navigation commands -- may also be useful.

During this exercise, you will learn how to compile a C program, how to correct errors&warnings, and how to use Linux system calls. You will also discover that it is more efficient to use buffers to write or read files to disk. Buffers are usually managed automatically by OS when reading/writing data, but our C code disables them in order to understand the interest of buffering.

1. Save the syscall.c file into your work directory, open it with your favourite text editor. You should be able to locate the use of the "open()" function. Verify that open() is a system call. Is printf() a system call? Then, find two other system calls that are used in syscall.c.
(Help me!) Use "man f" to know if a function "f" is a syscall or not



2. Now, read the code of this program in detail, i.e., find out its main purpose. More particularly, this program has two functioning modes that you should be able to explain.


3. Compile syscall.c to a binary file called syscall:

$ gcc -Wall -o syscall syscall.c

You should obtain warnings. Explain them, and modify the code accordingly so as to remove all the warnings.
(Help me!) A library needs to be included in the header part of the C file, and also another error to solve...



4. Execute syscall in mode 0.

$ ./syscall 0

The process should create a file, but fails because the file path refers to a directory where you don't have the right to create a file: /bin/foo1.txt. Then:

1. Add code after the "check if file was properly opened" in order to inform the user when the file cannot be created. Recompile, and test that you get an error message.
(Help me!) Test the value of "out_fd" where indicated



2. Modify in syscall.c the file name from /bin/foo1.txt to /tmp/foo1.txt. By using shell commands only, how can you easily verify that you don't have the right to create a file in /bin/ and that you have the right to create a file in /tmp?
(Help me!) echo > /bin/foo
A bit more tricky: [ -w /tmp/ ] && echo "w"




5. Execute the new version of your program (don't forget to recompile it). Once you're tired of waiting, return to the source code (stop the running program): you are indeed trying to create a (very) large file writing one character after another, which is quite inefficient: a better approach is clearly to use intermediate buffers: that is, writing several characters at a time.



What the provided code does	What your code should do
while(not over) { write(one character at a time) }	while(not over) { write("bufsize" characters at a time) }




6. From syscall.c, create a file named mysyscall.c that contains a program that can take one additional argument: the number of characters written at a time in the file.
Once your source file has been modified, test it (name your executable file mysyscall), and create a file (e.g., /tmp/foo1.txt). Using shell commands, verify that the created file contains the character 't', and that its size is correct.
For example:

$ mysyscall 0 2

(Help me!) To verify the size of foo1:
$wc -c /tmp/foo1.txt.
To verify the content of the file:
$cat /tmp/foo1.txt



7. Try various values of buffer, ranging for example from 1 to 4096 - or even much more -.
Measure the time it takes for each value. Do not forget between each try to first delete the file. For example, for a buffer of 512 bytes, type:

$ rm /tmp/foo1.txt; time mysyscall 0 512

Explain the various times which are printed (real, user, sys). Draw a curve showing the time it takes as a function of the buffer size. For convenience, you may use a data file (complete it), and use the following gnuplot script as follows to draw the curve:

$ gnuplot plot_io.gp

What can you conclude? How can you explain this?

Note that Operating Systems automatically handle buffers to read/write files from/to disk, and more generally for most input / output operations (network, etc.). To make experiments without OS buffers, a flag of the open() function in syscall.c deactivates OS buffering for the concerned file: O_SYNC.

Bonus work: Test the effect of buffers when copying files (second functioning mode of syscall.c).