Last updated 2009/11/06 18:29:25
Update history:
2009/11/06: |
initial version |
| 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.).
Note that 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.
The only required textbook for this course is Solaris™ Systems Programming, by Rich Teer, Prentice Hall, 2005.
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 optional textbooks for this course:
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 Solaris® 10, so the environment should be similar to what you have used in the main CS labs.
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 only access to the DSL from outside the lab
itself is ftp access to the DSL server; from the outside world,
you can connect to the server
ftp dsl
using an ftp command or application
to move files to and from your DSL account.
The DSL machines also have USB jacks which will accept flash drives.
To use a flash drive, simply insert it into one of the computer's
USB jacks, and the Solaris volume manager should examine it and (if it
has a file system that Solaris recognizes) automatically mount it into
the UNIX® file system.
The mounted drive will be found in
/rmdisk/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.
Important: you must unmount the drive before unplugging
it from the machine.
To do this, run the command eject rmdisk in a shell
window; when you see the next command prompt, it is safe to remove the
flash drive.
If you do not unmount the drive before removing it from the jack, Solaris
may "lock up" and not perform any more work until you re-insert the drive
or reboot the system.
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.
You can test your C projects on any CS system; however, your assembly language projects can't be tested on any non-x86 CS systems. 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). Of course, if you have access to an Intel machine elsewhere, you may be able to do testing of your projects there, as well.
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.
Note also that 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.
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.
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 6, 2009
Deadline to withdraw: Friday, February 5, 2010
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.