README - pub/scm/linux/kernel/git/mcgrof/cocci-tact - Git at Google

  cocci-tact: Demo for instrumenting with Coccinelle
 ====================================================

 This is a basic demo to show how one can do instrumentation with Coccinelle.

  The problem
 =============

 Some Linux kernel debugging features often require adding a lot of debug data
 structures to a source code repository, often this is addressed with
 CONFIG_DEBUG_* features but sometimes maintaining this upstream on Linux is not
 really welcomed due to how intrusive your changes may be or the difficulty
 in maintaining it properly. Sometimes such code can simply increase the
 complexity of what developers see, and can often riddle developers how to
 address its use / extending it / or replacing your instrumentation code.

  Instrumenting with Coccinelle
 ===============================

 Coccinelle enables a possible alternative: modify upstream code only when
 you need it, for a throw away debugging kernel. Your instrumentation then
 can be compartamentalized as much as possible upstream, and changes to
 existing code kept separate, outside of what developers see.

 This demo illustrates adding some form of instrumentation basic templates
 to code in userspace by trying to take advantage of a simple line which
 would be assumed to be upstream: on code pthread_mutex_protects_3().

 In this case pthread_mutex_protects_3() provides Coccinelle with hints
 over what data structures a mutex protects. It is the goal of the
 instrumentation mechanisms being developed here to either fix or
 debug this code without affecting readability for users or average
 developers of the code.

 This demo is written in userspace to help facilitate testing of ideas.
 Instrumentation ideas are not yet complete but its the hope this provides
 enough examples to show how this sort of work might look like. Locking
 would just be one area that could use this. There are obviously other
 domains that could benefit from this.

  Requirements
 ==============

   * Coccinelle >= 1.0.2
   * gcc
   * make

  Usage
 =======

 To see the problem run:

 	make
 	./main

 To see what the instrumentation does:

 	make coccicheck
 	git diff

 This doesn't do anything quite useful just yet.
	cocci-tact: Demo for instrumenting with Coccinelle
	====================================================

	This is a basic demo to show how one can do instrumentation with Coccinelle.

	The problem
	=============

	Some Linux kernel debugging features often require adding a lot of debug data
	structures to a source code repository, often this is addressed with
	CONFIG_DEBUG_* features but sometimes maintaining this upstream on Linux is not
	really welcomed due to how intrusive your changes may be or the difficulty
	in maintaining it properly. Sometimes such code can simply increase the
	complexity of what developers see, and can often riddle developers how to
	address its use / extending it / or replacing your instrumentation code.

	Instrumenting with Coccinelle
	===============================

	Coccinelle enables a possible alternative: modify upstream code only when
	you need it, for a throw away debugging kernel. Your instrumentation then
	can be compartamentalized as much as possible upstream, and changes to
	existing code kept separate, outside of what developers see.

	This demo illustrates adding some form of instrumentation basic templates
	to code in userspace by trying to take advantage of a simple line which
	would be assumed to be upstream: on code pthread_mutex_protects_3().

	In this case pthread_mutex_protects_3() provides Coccinelle with hints
	over what data structures a mutex protects. It is the goal of the
	instrumentation mechanisms being developed here to either fix or
	debug this code without affecting readability for users or average
	developers of the code.

	This demo is written in userspace to help facilitate testing of ideas.
	Instrumentation ideas are not yet complete but its the hope this provides
	enough examples to show how this sort of work might look like. Locking
	would just be one area that could use this. There are obviously other
	domains that could benefit from this.

	Requirements
	==============

	* Coccinelle >= 1.0.2
	* gcc
	* make

	Usage
	=======

	To see the problem run:

	make
	./main

	To see what the instrumentation does:

	make coccicheck
	git diff

	This doesn't do anything quite useful just yet.