Week of May 26th
3rd Week of Class

1. •Created our group
   

2. •Decided upon our basic goals
   

3. To create a data logging system across the kernel with accurate timing that will monitor data as it moves up and down the data path
   

4. •Did research on previous efforts into this field
   

Week of June 2nd
4th Week of Class

1. •Talked to Dr. Wang and various graduate students to try and figure out how file IO works in Linux
   

2. •This is a generalization from my own imperfect ability to fully follow the conversations but...
   

3. •There’s a lot of mystery about how the current version of Linux really works.
   

4. •Started playing around with printk
   

Week of June 9th
5th Week of Class

1. •Decided to move from printk to markers
   

2. •Upgraded my kernel version to 2.6.26.6 so that we would be using the same code
   

3. •Dr. Baker walked through the control flow of read statements with us
   

4. •Figured out how to implement markers and designed some basic test cases
   

Week of June 16th

6th Week of Class

1. •Decided to split the group up into two teams.  This spinoff is focusing entirely on tracing the read/write operations.
   

2. •Created a more robust marker management kernel module, named PirateAcorn
   

3. •Modified markers to support fine grained logging of read and/or write operations while excluding operations performed by logging software.  Also added the ability to log all read/write operations or only those performed by designated processes under obeservation
   

4. •Added markers throughout read/write functions in the kernel
   

5. •Started tracing the control flow of read write operations
   

6. •Presented my findings to the class
   

Week of June 23rd

7th Week, 1 Week After Class

1. •Created this webpage
   

2. •Worked on tracking down the one “Mystery Call” referenced to in the slides by calling “dump_stack()” to simulate an opps message
   

3. •As a refresher, here is the trace of the read functions for the program metacity
   

1. •And here is what I get when I call “dump_stack()” in do_sync_read for metacity
   

1. •As you can see, it pretty much just gives you the same information that I knew before.  This is kind of a chicken and the egg problem since I could see the trace location if I could insert a “dump_stack()” into it, but I don’t know what the call is to insert the “dump_stack()” into.  Note, this could probably be used instead of markers since you can see the system trace.  The advantage of markers though is the output is a little more readable and can be edited easier.
   

1. Success:
   

2. •Finally solved the problem, as I hadn’t enabled the marker for “net/socket/sock_read()”.  Once I did that, I was able to trace the read operations for metacity one level lower.  So apparently it was doing network communication even though it is the gnome window manager.
   

3. •This just goes to show what a pain doing function traces in an object oriented environment is.