高分，高分啊，，minix操作系统设计和实现一书，请问，如何编译minix操作系统光盘中的源代码？？？？

[XiaoRong2sxh]

minix操作系统设计和实现一书，请问，如何编译minix操作系统光盘中的源代码？？？？

如何编译一个操作系统？？？？？？

[XiaoRong2sxh]

up

[XiaoRong2sxh]

自己up以下

[XiaoRong2sxh]

没人会吗？？？

也是，好像也确实太难了，，

[nonocast]

4600 - Operating Systems, Summer 2000
Project Two - Minix System Calls


------------------------------------------------------------------------
PROJECT DUE DATE: June 23rd at 5pm
------------------------------------------------------------------------


PROJECT DESCRIPTION
------------------------------------------------------------------------
The purpose of this programming assignment is to learn how to modify
and rebuild the Minix operating system. We will learn this experience
by adding two new system calls to the existing Minix code.

You are to add a system call to Minix that accepts a process identifier
(PID) as a parameter and returns the process number (as stored in the
kernel's process table) of that process. You should call your new
system call getpnr().

You are also to add a system call to Minix that displays the current
contents of the process table. You should display only process table
slots that are not empty. There are several examples in the Minix code
that illustrate how to iterate through the process table. Some of them
can be found on pages 602, 668, 724, and 732 of your textbook. For each
process, you should display the process identifier, the process number,
and the process name. See the sample output section for suggested
formatting of your output. You should call this new system call
prproct().

Finally, you are to write a simple test program that will display the
process table, then display the results of calling getpnr() with the
current process's PID, and finally display the results of calling
getpnr() with the current process's parent's PID. Again, please see the
sample output section for suggested formatting of your output.

See the section of this project assignment entitled "IN-DEPTH REVIEW OF
MINIX SYSTEM CALLS" for a very thorough trace of the execution of a
system call in Minix. Your understanding of this process will prove to
be an invaluable asset for this and future projects.

To help you complete this project, here's the complete list of the files
you will either need to modify or create to complete this project:

/src/tools/project2.c
/src/lib/sunsyscall/Makefile
/src/lib/sunsyscall/getpnr.s
/src/lib/sunsyscall/prproct.s
/src/lib/posix/Makefile
/src/lib/posix/_getpnr.c
/src/lib/posix/_prproct.c
/include/minix/callnr.h
/src/mm/table.c
/src/mm/getset.c
/include/minix/syslib.h
/src/lib/syslib/Makefile
/src/lib/syslib/sys_getpnr.c
/src/lib/syslib/sys_prproct.c
/include/minix/com.h
/src/kernel/system.c

========================================================================
You must do your project independently. No copying of code will be
tolerated. Copying will result in a grade of zero, and will be reported
to the student honor court.
========================================================================



PROJECT REPORT REQUIREMENTS
------------------------------------------------------------------------
The report should consist of three parts:

Part 1: Describe any errors in your program and their locations in
the code. This is very important for partial credit. If the
program does not run, your description of the errors may be
the only way to get partial credit. You MUST use the report
in conjunction with the code printout to describe the
location of both logical and/or semantic errors that are
stopping the code from running. If you are unsure what the
error is, please state so. If there is any part of the
assignment that you have not completed, please note so
clearly in the report (even if your program runs). If your
program runs perfectly and is complete, then simply note
that.

If we find an error or incomplete program that was not
described, it will result in additional LOST POINTS (not just
for the error, but also for not mentioning it).

Part 2: Provide a printout of your code. It is suggested that you use
the output generated by minix_diff as your code listing.

Part 3: Provide a printout of a sample execution of your program.
To capture the output, use the "script" command as follows:

o Go to your Minix src/tools directory
o Issue the command "script project2.out" and press enter
o Run Minix as usual (sunread, execute your program, etc.)
o Exit Minix
o Issue the command "exit" and press enter

This will generate a file in your src/tools directory named
project2.out that contains a log of your Minix session.



ADDITIONAL REQUIREMENTS
------------------------------------------------------------------------
In order to receive full credit for this assignment, you must do the
following (in addition to getting the program working correctly and
writing the report):

You must put your full name and CISE username on the front page of your
report. If you have a cover page, put it on the cover page. If you do
not have a cover page, put it at the top of your report page. In any
event, your name and username must be clearly visible on the front page.

You must compile Minix and project2.c prior to the deadline. Your
compiled program should be named 'project2' and your source code should
be named 'project2.c' and both should be placed in your
~/cop4600/src/tools directory.

You must comment your code to the extent that someone who is not
familiar with your code can understand what your program does (in other
words, comment everything, and comment thoroughly). It is important
that your code be distinguishable from code previously existing in
Minix. You MUST encapsulate your changes in comments marking the
beginning and end of the changes, such as:

/* BEGIN PROJECT 2 MODIFICATIONS */

/* END PROJECT 2 MODIFICATIONS */

Also note that comments in the Makefiles begin with a "#" and extend
to the end of the line. C style comments (/* and */) do not work
in Makefiles. The same is true for assembly files (.s files).

Be cautious of spaces in Makefiles and .s files. Any line that is
indented from the left margin by any amount must be done so using a
tab, not spaces. If you get errors in your Makefile, this is almost
definately your source of error.

NOTE: Placing comments in the list of object files within a Makefile
tends to cause problems. For example, the following will compile,
but will cause problems (that are hard to find, since it compiles):

$(LIBRARY)(_pipe.o) \
$(LIBRARY)(_ptrace.o) \
$(LIBRARY)(_read.o) \
$(LIBRARY)(_readdir.o) \
# BEGIN PROJECT 2 MODIFICATIONS \
$(LIBRARY)(_rename.o) \
# END PROJECT 2 MODIFICATIONS \
$(LIBRARY)(_rewinddir.o) \
$(LIBRARY)(_rmdir.o) \
$(LIBRARY)(_setgid.o) \

To avoid these problems, you are not required to comment the lines
of code you add to the list of object files within the Makefiles.
You are, however, required to comment the actual instructions to
compile the files within the Makefiles, like this:

# BEGIN PROJECT 2 MODIFICATIONS
$(LIBRARY)(_getpid.o): _getpid.c
$(CC1) _getpid.c
# END PROJECT 2 MODIFICATIONS

Remember, you must comment your code IN ADDITION to encapsulating your
code in the BEGIN and END comments.



PROJECT UPDATES AND CHANGES
------------------------------------------------------------------------
>From time to time it is necessary to make updates or changes to project
assignments. If this is deemed necessary, the changes will be mentiond
during the next lecture session, emailed to all students on the cop4600
mailing list, and posted on the class web page.

[nonocast]

SAMPLE OUTPUT
------------------------------------------------------------------------
------------------------------------
PID P_NR P_NAME
------------------------------------
0 -10 TTY
0 -9 DP8390
0 -8 SYN_AL
0 -7 IDLE
0 -6 PRINTER
0 -5 HDDISK
0 -4 MEMORY
0 -3 CLOCK
0 -2 SYS
0 -1 HARDWAR
0 0 MM
0 1 FS
0 2 INET
1 3 INIT
29 4 sh
18 5 update
30 6 getty
31 7 getty
32 8 getty
33 9 project2

Process number of PID #33 is 9
Process number of PID #29 is 4



IN-DEPTH REVIEW OF MINIX SYSTEM CALLS
------------------------------------------------------------------------
The following is a detailed explanation of system calls in Minix:

Before you begin implementing these system calls, it may be helpful to
read through the following explanation of the execution of a typical
Minix system call.

As you may recall, there may be up to 77 system calls (see callnr.h on
page 561). Some system calls are implemented in the Memory
Manager (MM), others in the File System (FS), and still others in the
Kernel. However, a user program cannot directly communicate with the
Kernel; it must communicate with either the MM or FS, who in turn
relays the communication to the Kernel. For this project, we will
use the MM to act as the mediator between the user and the Kernel.

Let's track the execution of a system call from the user to the MM
to the Kernel and back.

When a system call is used in a user program, the compiler translates
it into an external reference (see src/lib/sunsyscall). If it is a
math library function, its code can be found in src/lib/math. If it
is a standard system call, a stub procedure must exist in the
src/lib/posix directory. A stub procedure does not contain the actual
code, but instead a call to the operating system. A typical stub
procedure just calls _syscall.

For example, the stub procedure for getpid looks like:

return(_syscall(MM, GETPID, &m))

This command calls the _syscall routine, indicating that the call is
intended for the Memory Manager, that the system call requested is
GETPID, and a message is passed containing any necessary information.
Communication between the user and MM or FS, or between the MM or FS
and the Kernel is usually accomplished by message passing, as
illustrated in this command. A message is a structure capable of
holding values, such as integers, for passing information, such as the
priority of the current process.

The syscall routine can be found in src/lib/other. It has a sendrec
call to the MM or FS. This sendrec makes the request to the receive
command in get_work, and it gets the reply from the send command in the
reply function. The get_work and reply functions exist in both the MM
and FS tasks, found on pages 751 and 829-830, respectively. For this
project, we will be using the MM get_work and reply routines.

At this point, control is passed to the MM. Let's take a look at how
the MM handles the system call. In the main routine of the MM (page
751), the MM calls get_work (line 16638) to get a call number from the
user process (lines 16667-16669). The MM looks up the appropriate
routine from the call_vector (page 749). You may notice that getpid
is associated with the number 20. Each system call is associated with
a unique number between 1 and 77. You may use any unused number(s)
for your system call(s). You must specify this association in callnr.h,
just as all other system calls are associated with their unique numbers
in callnr.h. From call_vector, you can see that the do_getset function
is called for the GETPID system call. The code for do_getset is shown
on page 780.

The do_getset routine is called for several system calls, actually.
You can see by the case statement which system calls are handled here.
One of the system calls handled is GETPID, the system call we have
been tracking.

GETPID, unlike the system calls you'll be implementing, is actually
handled by the MM, so there is no need for the MM to relay the
message to the Kernel. However, many system calls are implemented in
the Kernel. They are listed on page 726, in system.c. The MM is
responsible for communicating with the Kernel, and it does this by
means of a taskcall.

Since GETPID no longer serves our needs, lets take a look at the
FORK system call, which we know from our studies is implemented
(at least in part) by the Kernel. The fork system call to the MM
is translated into a call to do_fork (line 16832) by the same call
vector responsible for translating the GETPID system call into a
call to do_getset. After doing some work of its own, the MM must
tell the Kernel about the fork system call so that the Kernel can
do the work necessary to complete the system call. To tell the
Kernel about the fork system call, the MM calls sys_fork (line 16897),
which is a library routine that is translated into a taskcall to the
kernel. Unfortunately, these lines of code are not printed in the
textbook, but they are located in /src/lib/syslib/sys_fork.c.

After storing the information passed to sys_fork into a message
structure, we see that sys_fork calls _taskcall. _taskcall is nearly
identical to _syscall (see the comments in /src/lib/syslib/taskcall.c).
The first parameter specifies that we wish to communicate with the
SYSTASK (the Kernel). The second parameter specifies which system call
we wish to call (in the case of sys_fork, SYS_FORK), and the final
parameter is the familiar message structure, discussed previously.

Remember, a taskcall, like a syscall, is translated into a sendrec
call. The MM sends a message to the Kernel, who is waiting to recieve
a message at line 14844. Control is now transfered to the Kernel, who
accepts the taskcall and decides what action to take.

The Kernel calls a particular function based on the system call
desired, as indicated in the large case statement (lines 14847-14865).
For SYS_FORK, do_fork is called. The do_fork routine (page 729)
performs whatever actions the Kernel must perform for a fork system
call and then returns a value to the caller (the sys_task routine).
The sys_task routine breaks out of the case statement, and sends a
reply to the MM at line 14869. The MM receives that reply and
propagates the reply all the way back to the user program.

That thorough trace of a system call all the way from a user program
to the Kernel should provide you with the understanding you need to
complete the system calls required for this project



RUNAWAY MINIX PROCESSES
------------------------------------------------------------------------
PLEASE NOTE: Sometimes Minix will not exit properly and you will end up
with 'runaway' minix processes. This irritates the system group
immensely, and they will begin banning you from CISE machines if you do
not 'clean up' your runaway minix processes. To do this, follow these
instructions:

1) type "ps -u $user"
This will show you all processes you are running on the machine
you are logged into. If you see some listed as 'minix', follow
the next instruction. If there are no 'minix' processes running,
you may safely log out.

2) type "kill -9 "
Where is the PID of the running minix process. It is the
(usually four digit) number in the first column of the ps output.

[nonocast]

For example:

> ps -u $user
PID TTY TIME CMD
3010 pts/15 0:01 tcsh
3855 pts/15 0:04 minix
3922 pts/17 0:01 tcsh
> kill -9 3855

Always do this before you log out.



GRADING GUIDELINES
------------------------------------------------------------------------
1. Report (10%)

Your report must be clear and concise. Points will be deducted for
errors in your program that were not reported or for failure to
include all three parts of the report.

2. Style (10%)

The programming style must show readability of your program. Thus,
it must be well-organized. We'll look for how well you use comments,
how well you modularize the program, how meaningful the use and
naming of constants and variables are, which variables should be
global or local, etc.

When modifying Minix, style is very important. Make your code look
similar to the original Minix code, but add many more comments.
You should use highly visible comments that separate the code you
add to Minix from the pre-existing code, as well as line-by-line
comments describing the code you add (excluding simple statements).

3. Functionality (80%)

It is very important that Minix and your program compile. If they
do not compile without errors, your program will be considered
non-functional.

NOTE: If your program compiles but you did not make an effort to
implement most of the features required, your program is still
incomplete. In other words, turning in a program that technically
compiles but performs none of the functions requested is not
permitted.

If the program compiles but doesn't run we will use the report to
understand the errors and give partial credit.

If your program compiles and runs, we will test it according to the
project description and give you points based on how well you
implemented all that was required.



GRADING DISTRIBUTION
------------------------------------------------------------------------
This is an approximation of how grades will be assigned. We reserve the
right to change this grading criteria at any time without prior notice.

Report:
Correct bug reporting and inclusion of code and sample output: 8 pts
Placement of full name and CISE username on front page: 2 pts

Style:
Meaningful variable names, proper use of global/local scope: 5 pts
Adequate and thorough commenting: 5 pts

Functionality:
getpnr syscall works correctly: 30 pts
prproct syscall works correctly: 40 pts
test program works correctly: 10 pts

prproct displays empty slots: -5 pts
test program doesn't call getpnr
on parent process: -5 pts



HOW TO SUBMIT YOUR PROJECT
------------------------------------------------------------------------
This project is due no later than five o'clock in the afternoon on the
date given at the top of this description. Make sure your 'project2.c'
file is in your ~/cop4600/src/tools/ directory by the deadline, and make
sure you compile Minix and your test program ('project2') before the
deadline as well.

YOU MUST COMPILE MINIX PRIOR TO THE DEADLINE.

To compile minix, you must run 'mmake' in your ~/cop4600/src/lib and
~/cop4600/src/tools directories (in that order).

Additionally, you must turn in your report (described above) by the
project deadline. You may either bring it to class and give it to Dr.
Chow, or slide it under the TA's office door (room 430) by the deadline.
PLEASE DO NOT SLIDE REPORTS UNDER DR. CHOW'S DOOR.

IMPORTANT: It is highly important that you do not access your Minix
files or directories after the project deadline until
instructed to do so by the TA's or Dr. Chow. All Minix
directories must be archived after the deadline, and we
WILL check file timestamps to make certain no files were
modified after the deadline.

[Loveedom]

用gcc编译试试
不过gcc大概不能编译minix中的汇编语言部分
因为所用的汇编语言不一样
要用到minix中的CC编译器
看看这里 可能有帮助
http://www.cise.ufl.edu/~chow/cop4600/documents/project_2.html

[Loveedom]

你看看他的makefile呀
里面会有编译环境的

[deadcode]

书中所附光盘有个readme.txt,应该有说明