Last updated 2012/11/19 12:48:29
| Name: | Warren R. Carithers |
| Office: | 3617 Golisano (70-3617) |
| Phone: | (585) 475-5393 |
| Email: | wrc AT cs.rit.edu |
The goal of Systems Programming I is to provide students with exposure to and experience with the concepts and techniques related to the development and maintenance of operating systems and systems software.
The following are the intended outcomes for this course:
Students will be able to write and debug programs in a high-level language suitable for systems programming.
Students will be able to write and debug programs written in a low-level language suitable for systems programming and to interface low-level code to high-level code.
Students will be able to explain the principles underlying I/O device operation and programming.
Students will be able to write and debug programs which interface to an existing operating system at a low level to do process manipulation and interprocess communication.
This course has the following prerequisites:
From these courses, you should be familiar with the creation and use of standard data structures (linked lists, stacks, queues, trees, etc.), dynamic memory allocation, assembly language programming concepts (in some assembly language), and typical CPU organization (registers, memory addressing, etc.).
These are prerequisites, not corequisites - to succeed in SP1, you should have already passed all of these courses, or their equivalents. Taking them at the same time as SP1 is not sufficient! See me immediately if you are missing one or more of the prerequisites, or you may be dropped from SP1 without further warning!
Important note: Students who receive credit for SP1 cannot later take 4003-309 (C for C++ Programmers) for credit. If you took 4003-309 before taking SP1, you may find that the first weeks of SP1 cover familiar material; don't make the mistake of thinking that this will apply to the entire course, as we will quickly move on to other topics.
There is no required textbook for this course. The recommended optional textbook is The Linux® Programming Interface, by Michael Kerrisk, No Starch Press, 2010. Two alternate texts are:
Not all of the material we will cover this quarter comes from this text; you will have to depend on handouts and class notes for the other material.
The programming assignments for this course will be done in a combination of C and assembly language. Although they are not required, you may want to own a C or x86 assembly language textbook. I've had the bookstore order two additional optional textbooks:
Pointers on C is a particularly good choice for our course, as it focuses on the lower-level aspects of C. I selected Professional Assembly Language for a similar reason: it's the only x86 textbook I've seen that uses the GNU assembler, which means that its examples use the same syntax as the assembler we're using.
Your final grade will be based on three components: a series of programming assignments, a midterm exam, and a final exam. The distribution between these components is:
| 50% | projects | |
| 25% | midterm exam | |
| 25% | final exam |
Two exams will be scheduled for this course. The first is a two-hour midterm exam; the second, a two-hour non-comprehensive exam during finals week.
Currently, the best guess as to the dates of these exams are:
There will be four programming projects this quarter. All projects will be equally weighted. One will involve using assembly language alone, two will use C alone, and one will use both languages. Programming style standards for this course are based on those you've used in other courses.
Your work in this course will be done on the computers in the
Distributed Systems Lab (70-3610).
These are Intel-based systems running
Ubuntu® 12.04,
and the environment has been set up to be
very similar to what's installed on the systems in the main CS labs.
The lab has a laser printer called dsl_lw1 (also known as
watson, in keeping with the system naming scheme used in the
lab); all the DSL systems have been configured to use it as their default
printer.
The DSL has no lab assistant; you get in and out by using your RIT ID card. To gain access, you must have your ID entered into the security system; to do this, see Mark Stamer (70-3441), the CS hardware technician. Please don't do this for a few days; things tend to be very hectic at the beginning of the quarter, and you will not need to use the lab immediately.
For security reasons, the DSL is behind a firewall; there is no interactive access to the lab machines from outside the lab itself, so using these machines is less convenient than using the other CS machines.
The DSL server runs a web proxy server, so you do have access to the web from inside the lab, but only HTTP and HTTPS requests are forwarded. All the DSL systems are configured to use the proxy server by default, so accessing the web should be completely tranparent regardless of which browser (Firefox, Chrome, lynx, links, and links2 are currently installed) you use. No other access from inside the lab to the outside world is available.
The ony access to the DSL from outside the lab
itself is ftp access to the DSL server; from the outside world,
the DSL server is named dsl, and
you can connect to it using an ftp command (e.g.,
ftp dsl
within a shell window) or an ftp application
to move files to and from your DSL account.
The DSL machines have USB jacks which will accept flash drives.
To use a flash drive, simply insert it into one of the computer's
USB jacks; Ubuntu should examine it and, assuming it has a
file system that Ubuntu recognizes, automatically mount it into
the file system.
The mounted drive will be found in
/media/name (where name
is determined by the name used when the flash drive was formatted).
If there is no recognizable file system on the drive, it will not be
automatically mounted.
Unmount the drive before unplugging it from the machine.
To do this, you can either right-click on the desktop icon representing
the drive and select eject, or you can use the
df command in a shell window to determine the actual
device path (e.g., /dev/sdb1) and then run the command
umount /dev/sdb1;
when you see the next command prompt, it is safe to remove the
flash drive.
At some times during the term, it may be necessary to disable the automounting of flash drives so that the USB jacks can be used to create bootable media for the interrupt handling assignment.
Although you can test your C projects on any CS system, and your x86 projects on any x86-based CS system, all project submissions must be made on the DSL machines. In addition, the interrupt handling assignment can only be tested on the DSL machines, as it requires rebooting the machine to get your code running (this is frowned upon on the main-net CS machines).
Important note: All programming projects will be submitted for grading on the DSL machines, and therefore must work on those systems. If you choose to develop your solutions elsewhere, it is your responsibility to allow sufficient time to iron out any problems that may arise due to incompatibilities between your development system and the DSL systems. Programs that "work on my computer at home" but don't work on the DSL systems don't work.
The minimum acceptance test for project submissions
is that they must compile and link cleanly (i.e., without fatal
compilation or linking errors) when submitted with the try
command.
Emailed project solutions will not be accepted.
In addition to the graded assignments described above, a series of ungraded problem sets and their solutions will be posted to the course home page. Their purpose is to help you gain additional experience with the concepts and techniques covered in class. Although these will not be collected or graded, I suggest you attempt to work the problems before looking at the answers, to help ensure that you understand the concepts.
Academic dishonesty will be dealt with in accordance with DCS and RIT policies.
RIT's
Honor Code
(section 1 of the
RIT Students Rights and Responsibilities handbook).
A general statement that sets standards of behavior for all members of
the RIT community.
RIT's
Academic Honesty Policy
(section 18 of the
RIT Students Rights and Responsibilities handbook).
Defines the basic forms of academic dishonesty (cheating, duplicate
submission, and plagiarism) and explains the official RIT policy
regarding academic dishonesty.
The
DCS Policy on Academic Integrity.
Explains the official Department of Computer Science policy regarding
incidents of academic dishonesty.
RIT is committed to providing reasonable accommodations to students with
disabilities.
If you would like to request accommodations such as special
seating or testing modifications due to a disability, please contact the
Disability Services Office.
It is located in the Student Alumni Union, Room
1150; the Web site is
www.rit.edu/dso.
After you receive
accommodation approval, it is imperative that you see me during office
hours so
that we can work out whatever arrangement is necessary.
Disclaimer: Normally, the number, type, and relative weights of assignments will not change from those specified in the syllabus and other course documents. However, I reserve the right to make changes to these or any other facet of the course, at my discretion, based upon the events of the quarter; if such a change must be made, you will be notified in class, via electronic mail, and on my web page for the course.
Coursework: Unless otherwise specified in the assignment, all work you submit for grading must be your own. Code or ideas (specific algorithms, optimizations, etc.) obtained from or inspired by other sources must be properly attributed.
Due dates: I select due dates for assignments in order to provide adequate time to complete the assignments, while allowing sufficient remaining time in the quarter to complete the remaining assignments. Should it become necessary, I reserve the right to change due dates; this, in turn, may require modification of due dates for other assignments during the quarter, or (in some cases) elimination of some assignments.
System downtime on or near the due date for an assignment is not usually grounds for an extension. An exception to this is extended system downtime (on the order of multiple days, not just hours); if this occurs, I may consider modifying a due date, but this is not guaranteed.
Documentation and Programming Style: I expect students to follow some reasonable form of programming style. I don't mandate a specific style; for the most part, it's more important that your code be neat, clear, and (above all) consistent. Here are the major things I'm looking for:
An example style standard for C++ from CS4 can be found online in HTML, PDF, and PostScript form.
Warning: This course requires a significant amount of programming. I strongly suggest that you very carefully consider whether or not you should take any other programming courses along with it.
Withdrawing:
During the add/drop period (the first seven calendar days of the quarter),
you may drop this course and it will disappear from your transcript.
After that time, you can only withdraw from the course; the course will
appear on your transcript with a grade of W.
Deadline to add/drop: Sunday, December 2, 2012
Deadline to withdraw: Friday, February 1, 2013
Project submission: Unless otherwise indicated in the assignment, programming project solutions are to be submitted electronically by 23:59:59 (11:59:59pm) on the specified due date. Any day of the week is a valid due date. Solutions submitted through any other method (e.g., sent via email, slipped under my office door, put in the bin on the wall outside my office, etc.) will be ignored.
Examinations: If you are unable to take an examination for a good reason (by my standards), I expect to be notified BEFORE the exam takes place. Exams will be handed back to be gone over during class; they will then be collected and kept in my office.
Final Exam: RIT has an official set of Final Examination Policies which detail procedures related to the scheduling of final exams. Most important among these is the procedure to be followed by students who wish to request a change in date or time for an exam. Briefly, such a request is only accepted if the student has an exam conflict (i.e., two or more exams scheduled at the same time) or the student has three or more exams scheduled on the same day. Requests for rescheduling an exam must be submitted by the last day of week six.
Assignment of final grades:
|
I use a traditional 90/80/70/60 percentage-based grading scale in this class.
I reserve the right to alter these division points as I see fit at the end of the quarter if I believe it to be necessary, based on my overall evaluation of individual or class performance and effort. |
|
Grading:
This is not a lower-division course. Think about what this should mean to you. You will be expected to incorporate all you have learned so far into this course; i.e., you will lose points for not following assignment instructions, for submitting code that is sloppy, undocumented or unstructured, etc.
Late submissions are generally not accepted without my prior approval.
Your project submissions may be graded by a grader. If so, and you have complaints about your grade, first talk to the grader. If you are still convinced there is a problem and you are unable to convince the grader, come and see me.
All requests for regrading must be made within one week of the original return date for the assignment.