C语言代写|ECE391 Machine Problem 2


Device, Data, and Timing Abstractions

Read the whole document before you begin, or you may miss points on some requirements.

In this machine problem, you will extend a video game consisting of about 4,000 lines of code with additional graphical features and a serial port device. The code for the game is reasonably well-documented, and you will need to read and understand the code in order to succeed, thus building your ability to explore and comprehend existing software systems. Most code that you will encounter is neither as small nor as well documented—take a look at some of the Linux sources for comparison—but this assignment should help you start to build the skills necessary to extend more realistic systems. As your effort must span the kernel/user boundary, this assignment will also expose you to some of the mechanisms used to manage these interactions, many of which we will study in more detail later in the course.

Before discussing the tasks for the assignment, let’s discuss the skills and knowledge that we want you to gain:

• Learn to write code that interacts directly with devices.
• Learn to abstract devices with system software.
• Learn to manipulate bits and to transform data from one format into another.
• Learn the basic structure of an event loop.
• Learn how to use the pthread API.

Device Protocols: We want you to have some experience writing software that interacts directly with devices and must adhere to the protocols specified by those devices. Similar problems arise when one must meet software interface specifications, but you need experience with both in order to recognize the similarities and differences. Unfortunately,most of the devices accessible from within QEMU have fully developed drivers within Linux. The video card, however,is usually managed directly from user-level so as to improve performance, thus most of the code is in other software packages (e.g., XFree86).

We are fortunate to have a second device designed by Kevin Bassett and Mark Murphy, two previous staff members.

The Tux Controller is that funny little game controller attached to each of the machines in the lab.

The Tux Controller connects to the USB port of the lab machine. An FTDI “Virtual Com Port” (VCP) driver makes the USB port appear to software as a standard (old fashioned) RS232 serial port. We can then set up QEMU so that one of the emulated serial ports on the virtual machine maps to the emulated serial port connected to the Tux Controller. In this assignment, you will write code that interacts directly with both the (emulated) video card and the game controller board.

Device Abstraction: Most devices implement only part of the functionality that a typical user might associate with them. For example, disk drives provide only a simple interface through which bits can be stored and retrieved in fixed-size blocks of several kB. All other functionality, including everything from logical partitions and directories to variable-length files and file-sharing semantics, is supported by software, most of which resides in the operating system. In this machine problem, you will abstract some of the functionality provided by the Tux controller board.

Format Interchange: This machine problem gives you several opportunities for working with data layout in memory and for transforming data from one form to another. Most of these tasks relate to graphics, and involve taking bit vectors or pixel data laid out in a form convenient to C programmers and changing it into a form easily used by the Video Graphics Array (VGA) operating in mode X. Although the details of the VGA mode X layout are not particularly relevant today, they do represent the end product of good engineers working to push the limits on video technology. If you work with cutting-edge systems, you are likely to encounter situations in which data formats have been contorted for performance or to meet standards, and you are likely to have to develop systems to transform from one format to another.

Event Loops: The idea of an event loop is central to a wide range of software systems, ranging from video games and discrete event simulators to graphical user interfaces and web servers. An event loop is not much different than a state machine implemented in software, and structuring a software system around an event loop can help you to structure your thoughts and the design of the system.

Threading: Since the advent of faster processors, it became possible to exploit code parallelism by creating multiple threads. Multiple threads of execution also allow logical separate tasks to be executed using synchronous operations.

If one thread blocks waiting for an operation to complete, other threads are still free to work. Note that threads are different from processes. A thread is the smallest unit of processing that can be scheduled by an operating system.

Multiple threads can exist within the same process and share resources such as memory. Different processes cannot share these resources. On a single processor, multithreading generally occurs by having the processor switch between different threads, which is known as context switching. Since context switching happens frequently, the user perceives the threads as running concurrently.

In this machine problem, we illustrate the basic concepts by using a separate thread to get updates from the keyboard.

You will need to synchronize your code in the main thread with this helper thread using a Posix mutex. You will also need to add a new thread to take input from the tux controller. This thread may also need synchronization to guarantee correctness.

You may want to read the class notes on Posix threads to help you understand these interactions. Later classes will assume knowledge of this material.

Software examples and test strategies: In addition to these five learning objectives for the assignment, this machine problem provides you with examples of software structure as well as testing strategies for software components.

Two of the files include main functions that are only included when a defined value is changed at the top of the file. By setting this value to one and compiling the file by itself, you create an executable that tests the functionality provided by the file in the absence of other code. When you design software interfaces, you should do so in a way that allows you to test components separately in this manner and thus to deal with bugs as soon as possible and in as small a body of code as possible. Individual function tests and walking through each function in a debugger are also worthwhile,but hard to justify in an academic setting. The input control file allows you to develop and test your Tux controller code without using the game interface. Since the game changes the display to mode X, testing without the hassle of changing back to text mode can be quite helpful.

The modex.c file is compiled by the Makefile to create a separate executable that returns your system to text mode.
We also made use of a technique known as a memory fence to check some of the more error-prone activities in the file; read the code to understand what a memory fence is and what it does for you.

The Pieces Provided

You are given a working but not fully-functional copy of the source tree for a maze game along with a skeletal kernel module for the Tux controller. The Tux controller boards are attached to each machine in the lab.

The table below explains the contents of the source files.