Linux Internals - Assignment 2 - ourmon kernel module 
-----------------------------------------------------

When due:  wed at 5 pm, middle of final's week.

What to turn in:
	1. source listings
	2. makefile
	3. a short and pithy test plan document in ASCII please.
	You should state how you tested the driver.
	This should include output that shows that your driver works.
	4. write a short architectural overview of your work in ASCII.
	5. in addition, send all of that to
	cs572-hw@cs.pdx.edu 
	as a tar blob with no binary code please.  We will hand that 
	over to the TA.

Rough idea:

Take the basic ourmon module that is handed out and mailed out in class and 
port it to linux 2.6.  This is a module that is rough, worked on 2.4,
and will have some parts of it missing.  You have to repair it,
patch in missing features, add some hardwired C filters (to give it
something to do) and test it.

This should be a loadable "small" kernel ourmon probe module.

Ourmon is available and watchable at http://ourmon.cat.pdx.edu/ourmon

1. basic functionality:

ourmon installs itself as the tasklet soft interrupt side above
an ethernet device (or localhost) and receives a copy of every
packet coming into the device.  

It should test each packet for a set of dynamically configured-in
filters and increment per packet that set of filters.

Note you will need a timer and one or more spinlocks for protection of data.

You will also need to design a config file format, and read it
in at module loadtime.  This might be done by using /proc
for writing in the config or by opening a file in the kernel 
and reading in the contents.  (your choice).

Packets should be read out using reads (cat) from one of two possible
/proc/ourmon files as described in detail below.

Roughly your driver works like this:

	receive a L2 packet (L2/L3/L4/L7) data from the interrupt-side

	lock data structures
	
	run the packet thru 1 of 4 filters (depending on module
	insertion configuration)

	per filter
		increment per filter counters based on packet content

	unlock data structures
	
	free the pkt

re the timer:

	2 /proc files

	/proc/ourmon/unbaked
	/proc/ourmon/baked

	there are 2 counting structures which are the same as a data type.
	         
		the unbaked structure keeps runtime counts 
		for filters.   It is used by
		the main processing routine above to keep track
		of current counts.  The other structure is a finished
		copy of the current count structure -- hence call it
		"baked".  Normally one would read out the baked structure
		to find out the finished data for the last 30 seconds.
		unbaked can be read for debug purposes.

at 30 second intervals
	copy "unbaked" to "baked"
	zero out unbaked so that the stats start over. 

module insert time

	one passes in a simple ASCII config file.

	... etc ...

	init timer, spinlocks, etc.

Here are 4 hardwired C filters:

note: "other" below means not any of the preceding counters.
use unsigned long counters.  Each filter has a name and
possible input parameters (indicated by P1 ... P2).  
A filter will have some number of counters associated with it.
All the filters have at least two separate counters.

1. filter1 - pkt_counts

	count total TCP, UDP, ICMP, or other pkts.

	This filter has 4 counters, and all should produce counts.

2. filter2 - byte_counts

	count total bytes for TCP, UDP, ICMP, or other pkts.

	This filter has 4 counters, and all should produce counts.

3. filter3 - network  P1

	if packets belong to network P1 (P1 is a parameter),
	then count them, else count them as other.
	Count packets.  network means either IP src or IP dst.

	two counters:  network and other)

4. filter4 - TCP_port P1

	if packets belong to TCP port destination port P1,
	then count them, else count them as other.
	Count packets.

	two counters:  tcp_port and other)