As for previous projects, this is an individual or group project.
The project is due Thursday, March 22nd 2007, any time.
This project requires you to modify the Minix process manager, and in particular the implementation of the brk system call. Currently, the call fails when the predefined gap (as in p. 424) is exhausted. I would like you to modify the implementation of do_brk (servers/pm/break.c) to increase memory as needed. Specifically, when unable to satisfy a request, do_brk must now try to allocate a new data+stack space that is at least twice the size of the old space, and more than twice as big if so required to satisfy the call. If this succeeds, the old data space and the old stack must be copied to the new memory, the old memory can be deallocated, and of course the kernel must be asked to map the new segments.
If the new memory allocation fails, the call to do_brk should likewise fail.
I believe this can be done by putting all the changes into servers/pm/break.c, and if so, please send me this file. If you need to change multiple files, please send me the files you have changed (preferably the output of diff -c). In any case, please include a status report describing what you have done and how well it worked.
I have created a small test program, testbrk.c, to help you test your code. You can run it without your changes, and it should fail fairly quickly depending on the value of chmem: with a value of 41000 bytes, with me, the last line printed is:
incremented by 16384, total 32767
With your code in place, it should fail a lot later: on a linux machine with a gigabyte of memory, the final total was 1073741823.
Also note that testbrk does not do anything with the memory it allocates. It is therefore possible to successfully run testbrk without actually allocating the memory, simply by reporting success in the call to sbrk(2). This is clearly unsatisfactory. To test this case, I have created testbrk2.c, which actually accesses the allocated memory and should fail (or crash your system) if the memory is not correctly allocated. I suggest you use testbrk first, and only try testbrk2 when you are convinced your system code works.
Subsequent to the in-class discussion, I realized that this project has a flaw, in that any pointers into the stack become invalid after brk changes the virtual address of the stack. I suggest you test with simple programs such as testbrk that do not have pointers into the stack.