CS 354 Spring 2012

Lab 1: Getting Acquainted with XINU. Updated Jan 31, 2012.

Due: February 4th, 2012, 11:59 PM

Turnin activated

1. Objectives

The objectives of this introductory lab are to familiarize you with the process of compiling and running XINU, the tools involved, and the run-time environment. A part of this excercise is to get aware of the source code and its structure. Understand the concept of 'Process Table', its contents, and use the information stored.

2. Source Code, Compiling XINU and related reading

Download the source code and follow the instructions in the Setup Handout to compile and run XINU.
  1. XINU Setup handout
  2. XINU Source code
  3. Chapters 5 and 6 from the XINU textbook.
  4. Makefile Tutorial

3. What to do ?

Once you are able to compile the source code and make it run on linksys[XXX] router, you will see "Hello World!" on the terminal. This means, your code compiled correctly and XINU has booted on the router. You are now good to go with any of your code changes. Your task is as follows:

Task 1:

Write a XINU API that takes a process ID 'pid' as argument and prints the process related information using the process table 'proctab' (process.h)

Create a C source file "/system/print_proc_info.c" in the source package. Copy the API template (code snippet) using which new system calls (Kernel API) are developed in XINU. You have to code the logic for printing some process specific information. You should be able to display following info. Note that your API should print the process information only if the pid corresponds to a valid process in the XINU subsystem at that point of time.

XINU API Template

 1     /* print_proc_info.c - print_proc_info */
 2
 3     #include < xinu.h >
 4     #include < string.h >
 5
 6     /*------------------------------------------------------------------------
 7     *  print_proc_info  -  Prints the info in proctab for a given pid
 8     *------------------------------------------------------------------------
 9     */
10     syscall print_proc_info(
11         pid32   pid   /* process ID     */
12     )
13     {
14     intmask mask;     /* saved interrupt mask   */
15
16           /*-----  Declare variables to hold values  ------*/
17           /*-----  ------------------------------- --------*/
18
19     mask = disable();
20
21           /*-----  Your code for fetching process specific info and displaying them goes here -----*/
22           /*-----  ------------------------------- --------*/
23           /*-----  ------------------------------- --------*/
24
25
26     restore(mask);
27
28     }
29
    

The API has to return SYSERR if the value of pid is more than the maximum number of processes (NPROC) allowed in XINU or the process corresponding to pid is not a valid process.

For time being, ignore line nos. 19, 26. In brief, whenever you are developing a new system call, and modifying any of kernel/process specific varibles you don't want any other process to preempt and execute. Hence the disable and restore. You can also look at other SYSCALLs for you understanding, for e.g. receive.c , resume.c, etc. Note that the restore is to be executed whenever the system call or API returns even under error conditions.

Inorder to compile "/system/print_proc_info.c", you have to modify the Makerules files. Refer to section (4) below.

Task 2:

Here you will write code in system/main.c to test the API which you coded in "Task 1". Note that the macro 'NPROC' in source package denotes the maximum number of processes which can be spawned in XINU system. In main.c you will do following steps in order:

  1. In a loop where PID varies from 0 to NPROC-1, call your API with PID as the argument. Copy output to a document.
  2. Now, spawn 2 processes using 'create' and 'resume' system calls. Look for files create.c and resume.c and their function signatures. The 'create' system call requires a function pointer as the argument. The process created will execute this function. In order to make these processes persistent for some time, invoke the 'sleep' function with 10 seconds as argument. This sleep will keep the process in the kernel for sometime, during which your API (in Task 1) can fetch its data. Record the out in a document.
  3. Execute the same loop as in 1, and check to see if the process information of the 2 newly spawned processes in step 2 are shown using your API.

4. Files to look upon prior to coding

  1. include/process.h:
        Contains various macros, structs which are used everying in XINU code.
  2. system/create.c:
        Used to create a new process.
  3. system/print_proc_info.c:
        The API template where you have to put your code .
  4. system/main.c:
        This is the starting point when XINU boots.
  5. system/Makerules:
        Whenever, you make a new SYSCALL (like in Task 1) you tell the compiler about the whereabouts of the new file. This file contains the order in which files are compiled. It is in similar lines as that of a Makefile for any software package.

5. Testing

Your API should be well tested. It should return 'SYSERR' if the input pid is not a valid 'pid' existing in XINU subsystem as explained above.


6. Report

Paste the output from the terminal to a text document. You should be able to identify the newly spwaned process by displaying their process specific information.


Turn-in Instructions

Include the output text document in the xinu folder.

Electronic turn-in instructions:

        i) go to the xinu-12Spring-lab1-linksys/compile directory and do "make clean".

        ii) go to the directory of which your xinu-12Spring-lab1-linksys directory is a subdirectory (NOTE: please do not rename xinu-12Spring-lab1-linksys, or any of its subdirectories.)

                e.g., if /homes/jsr/xinu-12Spring-lab1-linksys is your directory structure, goto /homes/jsr

        iii) type in the following command

                turnin -c cs354 -p lab1 xinu-12Spring-lab1-linksys

You can write code in main.c to test your procedures, but please note that when we test your programs we will replace the main.c file! But, submit your code changes in main as part of your submission.

Also, ALL debugging output should be turned off before you submit your code.


Back to the CS 354 web page