|
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:
# Joe Citizen, s1234567 - Operating Systems Project 2
# CompLab1/01 tutor: Fred Bloggs
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:
- Ensure that you will never try to access a NULL pointer (defensive
programming)
- 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?
- 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.
- Check your makefile works
- 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:
- Describe and discuss what memory allocation algorithms
you could have used and justify your final design choice (20 marks).
- Describe and discuss the structures used by the
dispatcher for queuing, dispatching and allocating memory and other
resources (5 marks).
- Describe and justify the overall structure of your
program, describing the various modules and major functions (descriptions
of the function 'interfaces' are expected) (15 marks).
- Discuss why such a multilevel dispatching scheme would
be used, comparing it with schemes used by "real" operating
sytems. Outline shortcomings in such a scheme, suggesting
possible improvements (30 marks).
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 marks for the project.
In addition 30 marks 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. |
