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

iPodLinux Operating System Project: Implementing a System Call, Study Guides, Projects, Research of Operating Systems

A final project for the cmsc 321 - operating systems course, where students are required to implement a system call in the ipodlinux kernel and provide user-level test program(s) for testing the system call. The project must be done individually and the minimum requirement is to mimic the ps (process status) command. The system call should list the process id, user id, group id, process start time, and process name for all processes currently executing in the system. The output must be returned to the user-level program through a single char* parameter. The project offers possibilities for enhancement and provides resources to use.

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/17/2009

koofers-user-7ry
koofers-user-7ry 🇺🇸

10 documents

1 / 2

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CMSC 321 Operating Systems
iPod Project
iPodLinux System Call(s)
Due: 18:45 Friday 04 May 2007
Overview: For this final project you will implement one or more system calls in the iPodLinux kernel and
provide user-level test program(s) for testing your system calls.
This project must be done individually, without assistance from anyone else but me. You are free to use any
textbooks or online resources that you may find, but you are not allowed to copy code, and you must cite
any resources that you used.
Minimum Requirements: To meet the minimum requirements for this project, you must implement a
system call that mimics the ps (process status) command man ps for more information.
More specifically, for all processes currently executing in the system, for each process you must list the
process id, user id, group id, process start time, and process name. Refer back to the notes from earlier
in the semester on the process image struct task struct located in include/linux/sched.h. Much of the
information to be reported can be found therein, including cycling through the list of active processes. You
may choose, but are not required, to sort the output by process id.
Your output must be returned to the user-level program through a single char* parameter. For successful
completion of the system call, it is the user’s responsibility to have allocated sufficient space for the buffer
into which your system call will place its output. However, you are required in your system call to check if
sufficient space exists at the user level before you attempt to write to the user level (i.e., use verify area).
You system call must include an appropriate return value. Definition of this return value is at your discretion,
but generally 0 indicates success and -1 indicates failure.
Upon successful completion of the system call, the user level program should be able to print the contents of
the string parameter directly and show well-formatted output. In other words, it is up to your kernel-level
system call to handle formatting in the string returned to the user-level. The user-level program must be
able to invoke your system call similar to the following:
int returnValue = syscall(SYSCALL_NUM, psString);
if (!returnValue)
printf("%s", psString);
with resulting well-formatted output that looks something like the following:
pid uid gid Time Name
0 0 0 0 swapper
1 0 0 25 init
2 0 0 26 keventd
...
41 0 0 13553 userTest
(Note that, for iPodLinux, all processes will be run as root, so the user id and group id will always correspond
to root i.e., zero.)
Items You Need To Know:
A pointer to the current process is readily available (see include/asm-archnommu/current.h).
1
pf2

Partial preview of the text

Download iPodLinux Operating System Project: Implementing a System Call and more Study Guides, Projects, Research Operating Systems in PDF only on Docsity!

CMSC 321 — Operating Systems iPod Project iPodLinux System Call(s)

Due: 18:45 Friday 04 May 2007

Overview: For this final project you will implement one or more system calls in the iPodLinux kernel and provide user-level test program(s) for testing your system calls.

This project must be done individually, without assistance from anyone else but me. You are free to use any textbooks or online resources that you may find, but you are not allowed to copy code, and you must cite any resources that you used.

Minimum Requirements: To meet the minimum requirements for this project, you must implement a system call that mimics the ps (process status) command — man ps for more information.

More specifically, for all processes currently executing in the system, for each process you must list the process id, user id, group id, process start time, and process name. Refer back to the notes from earlier in the semester on the process image struct task struct located in include/linux/sched.h. Much of the information to be reported can be found therein, including cycling through the list of active processes. You may choose, but are not required, to sort the output by process id.

Your output must be returned to the user-level program through a single char* parameter. For successful completion of the system call, it is the user’s responsibility to have allocated sufficient space for the buffer into which your system call will place its output. However, you are required in your system call to check if sufficient space exists at the user level before you attempt to write to the user level (i.e., use verify area).

You system call must include an appropriate return value. Definition of this return value is at your discretion, but generally 0 indicates success and -1 indicates failure.

Upon successful completion of the system call, the user level program should be able to print the contents of the string parameter directly and show well-formatted output. In other words, it is up to your kernel-level system call to handle formatting in the string returned to the user-level. The user-level program must be able to invoke your system call similar to the following:

int returnValue = syscall(SYSCALL_NUM, psString); if (!returnValue) printf("%s", psString);

with resulting well-formatted output that looks something like the following:

pid uid gid Time Name 0 0 0 0 swapper 1 0 0 25 init 2 0 0 26 keventd

...

41 0 0 13553 userTest

(Note that, for iPodLinux, all processes will be run as root, so the user id and group id will always correspond to root — i.e., zero.)

Items You Need To Know:

  • A pointer to the current process is readily available (see include/asm-archnommu/current.h).
  • To allocate space within the kernel, use vmalloc (see include/linux/vmalloc.h).
  • Be very careful to match data types. Gaffes that you can get away with in user space can wreak havoc when done in kernel space. To interpret many of the named data types, see include/linux/types.h and include/asm/posix types.h.
  • If no output from your user-level test program shows when running ProgExec, one of two problems may be happening: either podzilla has gone awry (usually requires reboot) or you have mishandled memory in some way. To test the latter, try running your user-level program via the File Browser (navigate to, execute, and then open VT) — if you see lots of error messages, you have likely misman- aged memory at the kernel level.
  • Following is a very handy link for searching for items within the source code:

http://lxr.linux.no/source/?v=2.4.28;a=arm

This resource may not match exactly, but it works much better than grep.

Possible Dazzle:

  • Enhance your system call by displaying meaningful information garnered from the inode, dentry, and/or file objects discussed in the Chapter 12: The Virtual Filesystem handout. Note that for a given dentry object, the d path routine in include/linux/sched.h will write a full pathname into a buffer. Note that this stuffs the information into the end of the provided buffer.
  • Enhance your system call by printing the user name and group name instead of ids. Take a look at /etc/passwd and /etc/group on one of the Linux machines for an idea on how to get at this information. You may have to create/modify the existing files on the iPod. In addition to man pages, the following link may be a helpful resource for you on this:

http://yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html

  • Enhance your system call by displaying elapsed time rather than process start time.
  • Provide a separate system call that displays segment information similar to that you encountered in Nachos. The following link will be a helpful resource:

http://linuxgazette.net/112/krishnakumar.html

Write-Up: For this project, submit a brief README that describes your system call(s), its(their) parameters and usage, your user-level test programs, and citations of any references you use. Drop this README in the topmost linux-2.4.32-ipod2/ directory before gzipping for submission.

Submission: Create a gzipped tarball of your iPodLinux kernel:

tar -czvf iPodLinux-submit.tgz linux-2.4.32-ipod2/

and submit the tarball using the turnin command from the mathcs* network:

turnin -v -c cs321 -p iPod iPodLinux-submit.tgz

Your work on this and all projects in this course is subject to the conditions of the Honor Code as described in the course syllabus.