|
This week you will be putting the finishing
touches to your dispatcher and the documentation for the second project:
As for the first project you are required to
provide a makefile
with your project
makefile Support
Marking the project will entail the marker
recompiling your source code from scratch. To automate this process, a
requirement of the project is that your shell must be able to be built using
a make file. If you are using two source files hostd.c and pcb.c, both of which reference
the local 'include' file hostd.h, then your makefile should (at the minimum) look like this:
# OSmasters group - Operating Systems Project 2 hostd: hostd.c pcb.c hostd.h gcc hostd.c pcb.c -o hostd
Then your dispatcher is re-built by just typing make at
the command prompt if any of the .c or .h files have been changed since the last time the shell
was built.
Note that this makefile names the resulting executable file as hostd, another requirement of
the project. Note also that the third line of the above makefile - gcc hostd... - the action
line - must start with a tab.
Polishing:
1.
Ensure that you will never try to access a NULL pointer
(defensive programming)
2.
Are your comments such that someone else who has passed
Elementary Programming six months ago, but who has done no programming since,
could understand what your program and its functions are trying to do and how
your code is addressing those requirements? Could they, in the minimum amount
of time make alterations to the code to meet differing requirements?
3.
Check your implementation produces the same output as the
example hostd dispatcher in the
course home page. Note that example scripts have been provided in previous
exercises to illustrate the particular functionality of the dispatcher under
discussion. Those scripts (amongst others) will be used for marking your
project. Ensure that your dispatcher produces the required output.
4.
Check your makefile works
5.
Ensure that all files are named as requested (no upper
case characters).
Your documentation
This must be word-processed and handed in
separately. Make sure this complies with the requirements:
In a formal design document:
1.
Describe and discuss what memory allocation
algorithms you could have used and justify your final design choice (20 points).
2.
Describe and discuss the structures used by the
dispatcher for queuing, dispatching and allocating memory and other resources
(5 points).
3.
Describe and justify the overall structure of
your program, describing the various modules and major functions
(descriptions of the function 'interfaces' are expected) (15 points).
4.
Discuss why such a multilevel dispatching scheme
would be used, comparing it with schemes used by "real"
operating systems. Outline shortcomings in such a scheme, suggesting possible
improvements (30 points).
The formal design document is expected to have in-depth
discussions, descriptions and arguments. The design document is to be
submitted separately as a physical paper document. Note that this document is
worth 41% of the total points for the project.
In addition 30 points will be assigned to your
source code contributing 18% to your total project mark.
You should NOT hand in a copy of your source code with your
documentation.
Even if you have not implemented some of the
features (for example memory management) you should still 'describe and
discuss' to get the highest mark you can.
Re-read the project specifications and
ensure that you really do comply with what is requested NOT what you thought
was requested.
Code should be in 'straight' C using the
compiler of your choice (cc or gcc).
Always use nice to execute your test programs at lower priority to ensure
they do not inconvenience other users if they go 'haywire'. e.g.:
>nice a.out
The
descriptions of the system functions above are drawn from sources that
include manuals on the Sun Solaris system and the
MAC OS X Darwin/BDS system, and also from 'Advanced Programming in the UNIX
Environment', W. Richard Stevens, Addison-Wesley, 1993.
|
