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

解决方案 »

  1.   

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

  2.   

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

  3.   

    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 ing 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 MODIFICATIONSRemember, 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.
      

  4.   

    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 4IN-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 projectRUNAWAY 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.
      

  5.   

    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 3855Always 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 ptsStyle:
      Meaningful variable names, proper use of global/local scope:     5 pts
      Adequate and thorough commenting:                                5 ptsFunctionality:
      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 ptsHOW 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.
      

  6.   

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