Hints for A2

Quick Topic Links

general hints
_exit
argument passing
open, close, read, write
fork
testing

General

Don't forget to re-configure your kernel for Assignment 2, and to do all of your kernel builds in kern/compile/ASST2

% cd $HOME/cs350-os161/os161-1.99/kern/conf
% ./config ASST2
% cd ../compile/ASST2
% bmake depend
% bmake
% bmake install

Don't forget that if you add any new source files to the kernel code, you need to update the file kern/conf/conf.kern and you need to reconfigure your kernel. If you don't do this, the code in your new source file will not be included in the kernel build.

Don't worry about trying to reclaim physical frames in the kernel when they are no longer used. However, you should make sure that you kfree kernel memory that you've allocated using kmalloc but that the kernel no longer needs.

You may like to have lots of debugging information printing out from your kernel, but we don't want to see mountains of output when we run your kernel. OS/161 provides a DEBUG facility that can help with this problem - you can bury lots of debugging statements into your code, and you can turn them all off by just changing the value of a single variable. You can even turn them off conditionally by labeling them properly. To use this facility, you just include DEBUG statements into your code instead of kprintf, like this:

DEBUG(DB_EXEC, "ELF: Loading %lu bytes to 0x%lx\n", 
     (unsigned long) filesize, (unsigned long) vaddr);

The DEBUG macro and the various flags (like DB_EXEC) are defined in kern/include/lib.h. To control which DEBUG statements produce output, set the dbflags variable, which is found in kern/lib/kprintf.c. For example, setting

u_int32_t dbflags = 0;

will turn off all debugging output, while

u_int32_t dbflags = DB_EXEC|DB_THREADS;

will turn off everything except DEBUG statements that are labeled with DB_EXEC or DB_THREADS.

_exit

The partial implementation of _exit in the base OS/161 does not do anything with the exit status code provided by the the user program. Your complete implementation of _exit should properly handle the exit status code as described in the manual pages for _exit and waitpid.
Here is something to think about when you do start worrying about those exit status codes: a process's exit status code may be needed long after that process has exited. Where will you keep the code, and when will it be safe to forget it?

passing arguments

To pass arguments (argv) to a user program, you will have to load the arguments into the program's address space. In addition to the argument strings themselves, you have to create the argv array in the user program's address space - argv is an array of pointers to the actual argument strings.

Whenever you are loading data into an address space, you must ensure that it is properly aligned. Otherwise, the application will cause addressing exceptions when it tries to access the data. 4-byte items, like character pointers, must start at an address that is divisible by 4. So, it would be OK to start your argv array at an address like 0x7fffff08, but your application will run in to alignment problems if argv starts at an address like 0x7fffff09 or 0x7fffff0a, since those addresses are not divisible by 4. Characters are only 1 byte long, so there are no alignment issues. Your argument strings, which are character arrays, can start at any address.
A related constraint is that the stack pointer should always start at an address that is 8-byte aligned (evenly divisible by 8). This is because the largest data types that require alignment (and which might be pushed onto a stack) are 8 bytes long, e.g., a double-precision floating point value.
Make sure that you understand how argv and argc are supposed to work before you try implementing argument passing. As an example, consider the testbin/tail application, which expects two arguments. The main() function of tail looks like this:
```
int
main(int argc, char **argv)
{
	int file;

	if (argc < 3) {
		errx(1, "Usage: tail  ");
	}
	file = open(argv[1], O_RDONLY);
	if (file < 0) {
		err(1, "%s", argv[1]);
	}
	tail(file, atoi(argv[2]), argv[1]);
	close(file);
	return 0;
}
```
argv is a character pointer pointer - it points to an array of character pointers, each of which points to one of the arguments. For example, if the tail program is invoked from the kernel command line like this:
```
OS/161 kernel [? for menu]: p testbin/sort foo 100
```
Then the argv and argc variables should be set up as illustrated in the following illustration:

A detailed description of the expected set up of argv and argc can be found in the man page for the execv system call.

open, close, read, write

A call like this:
```
result = vfs_open("string", mode, &2vn);
```
is incorrect and should bring a warning from the compiler. The problem is that vfs_open may modify its first argument, but "string" is an unmodifiable literal. So if, for example, you want to open the console, you need to do something like this instead:
```
char *console = NULL;
console = kstrdup("con:");
result = vfs_open(console,mode,&vn);
kfree(console);
```
VOP_WRITE, VOP_READ, and other operations on vnodes want a uio structure as a parameter. kern/syscall/loadelf.c contains some useful examples of uio structures being setup and used for vnode operations.

fork

To implement fork, you will need to copy the address space, open file information, and trap frame from the parent process to use for the child process. When you do this, you need to watch out for potential synchronization problems. Specifically, you will need to make sure that the new thread does not go to user mode until its address space, open file information, and trap frame have been set up. In addition, you need to make sure that the parent process does not return to user mode until its address space, trap frame, and open file information have been copied.

testing

There are many OS/161 applications that you can use to test your kernel. The source code for many of these applications can be found under os161-1.99/user, in the testbin, uw-testbin, bin and sbin directories.
You build all of the OS/161 application programs when you run bmake in the directory cs350-os161/os161-1.99. When you do this, the application program executable files are copied into subdirectories under cs350-os161/root/.
Once your OS/161 kernel has booted, you can launch an application program using the p command from the kernel menu. For example, to run the palin program, which is located in testbin, use the following command
```
OS/161 kernel [? for menu]: p testbin/palin
```
As usual, you can pass commands to the kernel on sys161 command line, e.g.,
```
sys161 kernel "p testbin/palin"
```

The amount of memory in the default system is not very large. For some of the test applications, you may wish to increase the amount of memory by modifying the appropriate line in the sys161.conf file. Note that this must be a multiple of the page size (4096). For example:
```
# Old/default value
# 31      busctl  ramsize=524288
# Changed to 2 MB.
31      busctl  ramsize=2097152
```
In particular, you will probably have to do this for applications like forktest, farm and sty.