Hello Kuramochi, Zhenyu and Wan,

Here is your project description. 

I will get an up to date Sparc Linux kernel soon, but I think you could
start studying seriously now. 

- Peter -

Statistics and status information for Coda in /proc.
====================================================

Reporting Coda statistics and status information in the /proc file
system will be incredibly useful for improvements to the system.  I
used a directory /proc/coda in early 2.0 kernels and reported cache statistics there.  Unfortunately the /proc interface was changed and proc_register_dynamic was no longer available.  Now it will be a little more work to form the /proc files.

For generality we want a directory /proc/fs and coda would be a
subdirectory underneath.  In this directory you would report in a
variety of files the following:

- statistics of VFS operations.  How many lookups, mkdir's etc reached 
the Coda kernel code.

- statistics of upcalls the kernel Code makes to Venus.  The 2.1
kernel fills in this structure but it is currently not displayed
anywhere.  The upcalls from the kernel to Venus also compute the time
it takes to make an upcall and averages, perhaps standard deviations
should be reported for each type of call.

- statistics of cache hits for permissions. The permissions granted to 
processes are cached.  How often do we have a hit? How often do we ask 
Venus?

- statistics of cache invalidations: Venus can notify the kernel that
cached file information in the kernel must be flushed.  (The zap_*
calls.).  Present the statistics counting these operations. 

- make new proc sysctl entries in /proc/sys/coda to reset the
statistics to 0 for each of these.

The functional /proc/sys/coda directory is also important.  Here we
want to add a few entries which reset the statistics back to 0.

Use a 2.1.8? kernel.  I will provide a kernel for Sparc Linux in this
family, but you could start by looking on an intel machine.

Your learning ground is to look at /proc/net -- there are many files
implemented by /proc/net.  Such files are instantiated with
proc_register functions.  These take structures as arguments, which
hold pointers to functions to read/write the files.  On the whole you
should use proc_net_inode_operations whereever possible since this is
a good set to work with.

A) In /usr/include/linux/proc_fs.h you can define the inodes for /proc/fs
and /proc/fs/coda.  The in the latter directory define inode numbers
for the statistics files you want.

Find out when to register these inodes from the Coda file system
module -- it can clearly only be done if proc_fs is defined as a file
system (look in the networking code).

B) Use the upcall structure statistics as a starting point. It is
recorded by routines like clstats defined in
include/linux/coda_psdev.h.  The key issue is to write the routine
"get_info", which is called when a read is performed on the
/proc/fs/coda/yourfile.

TARGET 1: /proc/fs/coda exists and a single file is created called
hello-world which contains "hello-world".  Define a good pool of 4 or
5 important inode numbers for reporting the statistics.

The behaviour of this file should be good, i.e. if coda.o is unloaded
as a module, the file disappears.

In the Coda kernel sources for version 2.0 (this is in directory:
kernel-src/vfs/linux; the 2.1 source is in kernel-src/linux21.) you
find a complete example of the function cfsnc_get_info which reports
statistics of the namecache (which was obsoleted under 2.1).

TARGET 2: /proc/sys/coda/hello-world-control is a file that you can
use as follows:

echo 1 > /proc/sys/coda/hello-world-control
and the text in /proc/fs/coda/hello-world changes.

TARGET 3: build in the statistics for most operations.  You need to
look at upcalls (largely done) and all the fs_operations for files,
superblocks and directories.

Good luck.  Keep me posted.

- Peter -