Hints for A2b

Quick Topic Links

argument passing
file I/O
gdb
testing

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.

File I/O

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.
Since vfs_open may modify its first argument, it is generally a good idea to make a copy of that argument and then pass the copy to vfs_open. For example, if fname points to a string representing the name of the file to be opened, you can use code similar to this:
```
char *fname_temp;
fname_temp = kstrdup(fname);
result = vfs_open(fname_temp,mode,&vn);
kfree(fname_temp);
```
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. The uio structure itself is defined in kern/include/uio.h.

gdb

gdb is can be very useful for poking around in memory, especially when you are trying to implement argument passing. When you are printing pointer values, you'll probably find it handy to have them displayed in hex, rather than decimal. This is easy to do with gdb. For example, suppose you have a pointer variable called argsarraystart, and you want to know its value. By default, it will print as a decimal number:
```
(gdb) print argsarraystart
$5 = 2147483616
    
```
However, you can simply ask gdb to format it as hex:
```
(gdb) print /x argsarraystart
$6 = 0x7fffffe0
    
```
you can also use gdb to print the value stored at any memory location that can be mapped by the kernel (based on the current contents of the TLB). For example:
```
(gdb) print *(char *)0x7fffffe8
$17 = 117 'u'
    
```
The (char *) in this command tells gdb to treat the address 0x7fffffe8 as a character pointer. The leading * tells gdb to dereference that address and print the value stored there. This is an easy way to see whether things are as you expect them to be in memory. For example, once you have copied arguments into a new address space, you can inspect the address space to see if things are laid out as you expect.

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
```
To evaluate the kernel you submit for Assignment 2b, we will first re-run the Assignment 2a tests. In addition, expect to run at least the following test programs to test your implementations of execv and argument passing. We will run these using both single processor and multi-processor configurations.

uw-testbin/argtest

When run from the kernel command line, this tests the passing of arguments to the initial process (the one created by a call to runprogram).

testbin/add

When run from the kernel command line, this tests the passing of arguments to the initial process (the one created by a call to runprogram).

uw-testbin/argtesttest

This tests fork and execv and argument passing through execv.

uw-testbin/hogparty

This tests fork and execv, and does not require argument passing.

testbin/sty

Like hogparty, this tests fork and execv. Unlike hogparty, it also tests waitpid.