COMP 3000 Lab 7 2012

From Soma-notes
Jump to navigation Jump to search

In this lab you will be taking a tour of parts of the Linux kernel source code in the course of answering a few specific questions. Along the tour you'll be required to answer some simple questions. Note that these questions are generally meant to be straightforward and should require very short answers.

There are 10 points in 10 questions, with one extra credit question worth 2 points. The lab is due on Wednesday, November 28th, by 11:55 PM.

If you just look up the answers to this lab you will miss the point of this lab. Try to tie the material covered in lecture to what you see in the code. There are a few "LEARN:" notes. These are things you should figure out if you don't know them already. You won't be graded on them in this lab; however, expect them to show up on the final in some form.

You can go through this lab by looking at a local copy of the linux source code (downloadable from the Linux Kernel archives or by looking at the Linux Cross Reference (using the 2.6.11 and later branch).

The Linux Banner

QUESTION: What code prints the "Linux version" banner when the kernel first starts up?

The Linux kernel's architecture-independent start-up code is in the init directory. As you might guess, the main startup code is in init/main.c, with the necessary routines being called by the function start_kernel(). In this function there is a printk that references linux_banner.

1. What is the log level of the banner printing printk?

LEARN: What are kernel log levels? What are they used for?

Now, the definition of linux_banner is not this file, but is instead in init/version.c. This file is not referenced, however, by init/main.c.

2. What file declares linux_banner for init/main.c?


QUESTION: If you look in /proc/<PID>/ (the process-specific directories) you'll notice a file called "syscall". It requires privileges to read this file. But what is it for?

First, let us find where the code is that produces this file. First, run df /proc. You'll note the filesystem is of type "proc".

3. How much space is used in /proc?

LEARN: What does it mean to mount a filesystem? What file specifies static mounts like /proc?

LEARN: What storage is associated with /proc?

The code for the proc filesystem is in fs/proc. But where is the code for this particular file? Well, if you look in fs/proc/base.c, you'll find a struct call tgid_base_stuff. In this, you'll see the string "syscall" is associated with the function proc_pid_syscall().

4. What type is tgid_base_stuff?

5. The directory fd is associated with two pointers to structs. What are they?

LEARN: Why are there two functions associated with every directory? What do they each do?

Look at the code of proc_pid_syscall(). In this function, there is a call to task_current_syscall() (in lib/syscall.c), which does the real work. The comments for that function indicates that it is used to "Discover what a blocked task is doing." Thus, /proc/<PID>/syscall gives information on the current system call being executed by a process, if any.

6. What variable holds the current system call number in proc_pid_syscall()?

7. What variable holds the current system call number in task_current_syscall()?

8. What function is used to output the system call number and other information into the file /proc/<PID>/syscall?

syscall numbers

QUESTION: What code converts system call numbers to internal kernel functions?

The system call entry into the kernel for x86-64 is defined in arch/x86/kernel/entry_64.S. This is an assembly language file. The main entry point is defined at ENTRY(system_call). The actual system call function invocation is done with the line:

call *sys_call_table(,%rax,8)

Note there are two calls to this, one for the regular path and one for the "fast path". Also, notice the call schedule lines in this file. These are where the scheduler gets invoked.

9. What nearby lines check whether the system call number requested doesn't exist (is a number bigger than any defined system call)? Note there are two of them, depending upon a compile time config option.

Now the system call table is defined in another file (of course), arch/x86/kernel/syscall_64.c, with the actual calls coming from a compile-time generated file. The system call numbers, however, are defined in x86_64-linux-gnu/asm/unistd_64.h

10. What is the system call number of getpid?

LEARN: Why is this file in assembly language rather than C? Specifically, what tasks must this code do that is difficult, if not impossible to do in standard C?

11. [2] (EXTRA CREDIT) What is this generated file, and how is it generated?