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
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
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
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)
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
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
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.
Questions or comments regarding 6.828? Send e-mail to the TAs at
6.828 home //
Last updated Friday, 02-Oct-2015 15:05:07 UTC