News

• Dec 17, 2008: Remember that the final exam is on Friday at 9:00AM in DuPont. You can bring any printed material you like. Please bring printouts of the assigned papers and of xv6. The final will concentrate on the second half of the course; however, some questions will draw from your knowledge of xv6 and JOS. Here are some old finals.

• Dec 2, 2008: The final project check-off sign up page is open.

• Nov 29, 2008: Read Bugs as Deviant Behavior for Monday, and do the homework.

• Nov 15, 2008: Lab 7 is out.

• Nov 6, 2008: Lab 6 is out.

• Oct 29, 2008: Lab 5 is out.

• Oct 17, 2008: Here are the quiz solutions.

• Oct 9, 2008: Next week office hours will be moved to Tuesday 2pm to 3pm and Thursday 5pm to 6pm. No office hours Monday due to Columbus Day holiday.

• Oct 5, 2008: Lab 4 is out.

• Sep 27, 2008: Wednesday, Sep 24 Survey Question Answers

  • For finding out more information about x86 instructions (like pushal and int) take a look at the IA-32 Intel Architecture Software Developer's Manuals listed on the class reference page.

  • Some of you had a question regarding line 2668 in XV6. Think about these two situations:

        addr = p->sz - 2
      

    If the if statement contained only addr >= p->sz, then the fetchint function would fail to reject this address. This is where the addr + 4 >= p->sz comes into play. From this example, it might be tempting to conclude that addr + 4 >= p->sz is sufficient to check whether address is valid. However, what if:

        addr = 0xfffffffc
        addr + 4 = 0
      

    which is true and addr + 4 >= p->sz alone fails to reject; addr >= p->sz, on the other hand, rejects this address if p->sz is in fact less than 0xfffffffc.

• Sep 22, 2008: Lab 3 is out.

• Sep 18, 2008: Final exam will be on Friday, Dec 19th, 9am-12noon in duPont.

• Sep 17, 2008: Monday, Sep 15 Survey Question Answers

  • How does initcode.S get called, where does it come from, and why?

    Background: Unix operating systems have a process that is responsible for setting up the environment that the user sees (starting up terminals, etc.). This process is called "init". It is the very first user level process and is assigned the special PID 1. initcode.S and the userinit function start up this user level process (the source can be found in init.c) in xv6.

    Now on to the code: The code responsible for getting the initcode.S running is in function userinit on line 1757. Stepping back, if we take a look at the Makefile, we can see where initcode.S comes from.

     1 initcode: initcode.S
     2         $(CC) $(CFLAGS) -nostdinc -I. -c initcode.S
     3         $(LD) $(LDFLAGS) -N -e start -Ttext 0 -o initcode.out initcode.o
     4         $(OBJCOPY) -S -O binary initcode.out initcode
     5         $(OBJDUMP) -S initcode.o > initcode.asm
     6
     7 kernel: $(OBJS) bootother initcode
     8         $(LD) $(LDFLAGS) -Ttext 0x100000 -e main -o kernel $(OBJS) -b binary initcode bootother
     9         $(OBJDUMP) -S kernel > kernel.asm
    10         $(OBJDUMP) -t kernel | sed '1,/SYMBOL TABLE/d; s/ .* / /; /^$$/d' > kernel.sym
    

    Lines 1-5 above generate the initcode used in the function userinit. On the second line, initcode.S is compiled and on lines 3 and 4 packaged as a binary file called initcode. Notice that on line 3, the default entry point is "start" and that the code is linked starting at address 0. This means that the initcode binary expects to be loaded so that the "start" function is at address 0.

    After initcode is compiled, it is linked into the kernel so that it can be used by userinit during runtime. The linking takes place on line 8; notice initcode at the end of the line. The symbols _binary_initcode_start, _binary_initcode_size and _binary_initcode_end are added by the linker on line 8 and the symbols can be found by looking at the kernel.sym file (this file is generated by the command on line 10).

    Now on to line 1780: the initcode binary file is loaded into the page allocated by the function on line 1764. Since the code was linked to start at address 0, line 1779 sets the eip to start at virtual address 0. (Since initcode.S is a assembly file and was written so that the entry point is at the start of the file - virtual address 0 - there is no need to look up what the entry point should be as we did in the bootloader when loading the ELF kernel binary.)

    On line 1784 the process is marked as runnable and the initcode returns to the main function on line 1236. On line 1239 mpmain is called that among other things calls scheduler at the very end on line 1263. The scheduler function on line 1808 find the process that we created in initcode and executes it on line 1832. The detail of the switch will be covered in a latter lecture. However, generally speaking, the switch will set the eip to p->tf->eip (look at line 1779) and will start executing from there.

    Now to answer the question "why!?". Xv6 has a mechanism to take an existing user process and fork a new user process. This new process can continue executing the code or call exec to load a new application off of disk and run it. However, before init is started, there are no user processes at all; init is the very first user process. Therefore, we cannot use the fork and exec to start the init process because fork and exec need to be called from an active process. To start init, xv6 actually needs to create a user process first. How do we do that? We can setup the address space (using segments), create a stack, a heap and an area for code. We can then load some code into the code area and execute it. (This is exactly what userinit does.) What code should we load into this newborn process?

    We can load the init code directly. This will require reading the ELF binary and doing exactly what we did in the boot loader. This will require duplicating the ELF loading code (There is such code in the boot loader and in the exec system call already, we do not want to introduce more). Is there a better way? We already have code that does exactly that, its called exec! This is where initcode.S comes in. initcode.S is a wrapper around the exec call that loads /init.sh from disk and runs it. Exactly what we need; a small amount of code that will run in a user process and exec the init process. The initcode.S code is very simple and short; we do not need to duplicate code or create new special purpose functions in the kernel to get the first process off of disk and into memory.

  • There were comments about the xv6 code walk through. Some of you found it confusing. The best approach is for you to read the assigned code ahead of time (send in any questions to the TAs) and be ready for a walk through in class. Many of our lectures from now on will have exactly this format: high level detail at the beginning of the class followed by a detailed walk through the xv6 code demonstrating the concepts learned in the first part of the lecture. Also you will need to get comfortable paging through the xv6 code book for lectures and your quiz and final.

  • Is paging per process? Each process has its own page table and its own address space. More on that next lecture.

• Sep 16, 2008: There will not be office hours this week on Wednesday. Instead, Thursday office hours will be held from 2pm to 4pm. If you can't make these hours, let us know.

• Sep 11, 2008: Homeworks 3 and 4 are now posted.

• Sep 11, 2008: Labs are due at 11:59PM on the due date posted on the lab assignment page.

• Sep 11, 2008: Here is a summary of the questions and concerns gathered from the surveys last Wednesday.

  • The most popular questions/comments were regarding segmentation and virtual memory. We will cover and go into much greater detail more of this next week.
  • Some of you wanted to know more about microkernels and exokernels. If you have not read the Exokernel paper, you should look at least at the introduction, related work and conclusion sections. The paper has an explanation of an exokernel and how it differs from a microkernel.
  • Office hours are Wednesdays and Thursdays from 2pm to 3pm in the Stata G9 lounge. More info can be found here.

Top // 6.828 home // Last updated Wednesday, 22-Sep-2021 12:14:44 EDT