Can events be applied to LITMUS code instead of sched_task_trace ?

PROS:
	- architectural indipendency
	- easy porting on newer kernel version
	- lock free ring buffer implementation already there

CONS:
	- need userspace tools conversion to slightly different format
	- is it possible to replicate all the previous functionalities?
	- only sched_trace_* functions can be implemented through events,
	  TRACE() debugging features are still implemented in the old way
	  (??? cannot we simply use the tracing features of the kernel for
	   debugging purposes ????)

 - fix requesting more than 2^11 pages (MAX_ORDER)
   to system allocator

to be merged:
 - feather-trace generic implementation

to be merged:
- SRP (sched.c)
- feather-trace implementation (to be fixed)
- sync support (KConfig)

litmus_sched_class implements 3 new methods:
.prio_changed:
  void
.switched_to:
  void
.get_rr_interval:
  return infinity (i.e., 0)

On the parisc architecture we face for each and every loaded kernel module
this kernel "badness warning":
  sysfs: cannot create duplicate filename '/module/ac97_bus/sections/.text'
  Badness at fs/sysfs/dir.c:487

Reason for that is, that on parisc all kernel modules do have multiple
.text sections due to the usage of the -ffunction-sections compiler flag
which is needed to reach all jump targets on this platform.

An objdump on such a kernel module gives:
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .note.gnu.build-id 00000024  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00000000  00000000  00000000  00000058  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .text.ac97_bus_match 0000001c  00000000  00000000  00000058  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .text         00000000  00000000  00000000  000000d4  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
...
Since the .text sections are empty (size of 0 bytes) and won't be
loaded by the kernel module loader anyway, I don't see a reason
why such sections need to be listed under
/sys/module/<module_name>/sections/<section_name> either.

The attached patch does solve this issue by not exporting section
names which are empty.

This fixes bugzilla http://bugzilla.kernel.org/show_bug.cgi?id=14703

Signed-off-by: Helge Deller <deller@gmx.de>
CC: rusty@rustcorp.com.au
CC: akpm@linux-foundation.org
CC: James.Bottomley@HansenPartnership.com
CC: roland@redhat.com
CC: dave@hiauly1.hia.nrc.ca
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>