| UNIVERSITY OF WISCONSIN-MADISON
Computer Sciences Department |
||
| CS 736
Fall 2011 |
Barton Miller |
The project suggestions below are briefly stated. They are intended to guide you into particular areas and you are expected to expand these suggestions into a full project descriptions. This gives you more freedom in selecting an area and more burden in defining your own project. There may be more issues listed for a project than you can cover. If you have a topic of your own that is not listed below, you should come and talk with me so we can work out a reasonable project description.
You will write a paper that reports on your project. This paper will structured as if you were going to submit it to a conference. I will provide more details on the project report later in the semester.
You should work in teams of two people (and, in certain cases three people) on the project and report.
With Dyninst, you can extract structural information such as control flow and call graphs, and identify functions, basic blocks, and instructions. You can instrument code and patch it to change its behavior, either statically (before execution) or dynamically (during execution).
The goal is to choose some analysis, instrumentation, or control task, and build a Dyninst-based tool. The task could be in the area of tracing, program analysis, modeling, cyber-security and forensics, performance profiling, or debugging.
You will have to choose a threading environment, probably pthreads, understand what type of controls an application program has over the scheduling decisions, and how you will manipulate these controls under test. You will also have to choose a set of programs to test and (when you find bugs), identify the causes of the bugs.
As far back as 1984, Unix developers saw /proc as a better way to control processes. The Solaris operating system (Sun's version of Unix) developed a nice version of /proc (which was also used by IBM in AIX and SGI in Irix). The Plan 9 operating system further extended and cleaned up /proc.
The goal of this project is to modify and extend a recent version of Linux to use /proc for debugging purposes. You are free to choose which specific version of /proc that you want to support.
If we accept the approach from Dthreads, then it is natural to ask if we should be programming in a way that has a simpler API that more closely matches the semantics guaranteed by Dthreads. Such an interface might be smaller, simpler to program, simpler to implement, and potentially provide better performance under the Dthreads techniques. The goal of this project would be to develop such an interface and prototype it.
In recent years, it appeared that the dominant and quasi-standard version of Unix had become Linux. Such standardization would allow it to compete with Windows on a more equal footing; a software developer knew that if they ported their software to run on Linux, it should run on all distributions of Linux.
Unfortunately, the various Linux distributors (such as Red Hat, Tao, Ubuntu, and SuSE) are now adding their own code, so that they distinguish their distribution. In some cases, it is merely additional services on top of Linux, but in other cases, they are changing the kernel, its interface, and the way that the software is built and linked. These changes cause incompatibilities that might balkanize the Linux world.
The goal of this project is to study the basic Linux kernel, runtime libraries, and basic utilities, to identify the ways in which some of the common distributions vary. These results are interesting both qualitatively (what kinds of things change and in what areas?) and quantitatively (how much of the code changes?).
Your project proposal will describe your goals, methods, implementation outline, evaluation criteria, and resources needed. First, you should describe the basic problem that you will be addressing. Next, you should provide a more detailed description of how you will approach the problem. This description should be contain much more detail than the brief paragraphs given above. You will provide an outline of features that you project will include, an implementation plan, and an evaluation plan.
Project proposals will typically be 3 to 4 double-spaced pages.
In general, a referee report starts with a summary of the main idea(s) in the paper, and then has an overall statement of the quality. You should then review the main technical ideas. In addition, either a marked-up copy of the paper, with typos and related errors, or a summary of typos and related errors should be given to the authors.