This quick tracepipe patch is an attempt to make it trivial for a
developer to generate debugging traces in the kernel and get them to
mass storage without having the tracing enormously skew behaviour.  It
is built off of Greg's debugfs and Linus' advocacy of efficient buffer
transit with pipes and pipe_buffers.

A kernel subsystem registers a file in debugfs and gets a struct cookie
in return.  The file that is created uses fs/pipe's file_operations but
wraps its own open and release tracking around it.

While it's running the kernel subsystem can send binary blobs, less than
the length of a page, down this channel.  The blobs are copied into
per-cpu lists of pages.  Cutesy little headers with get_cycles() and the
cpu id are prepended to each blob.  The traces are only recorded if user
space has open references to the file.

As the pages fill they're kicked off to a work_struct worker who puts
them in the bufs[] array in the debugfs pipe file.  Userspace can then
do whatever it wants with the data via the pipe.  One can imagine it
wanting to splice() these pages to disk in huge batches, or perhaps some
zero-copy network card, etc.  I've only tested this so far as verifying
that 'cat' is able to push data into a regular file.

I didn't aim for for optimal behaviour before sending this patch out.
I'm looking for comments.  There's lots of room for improvement,
particularly in reducing synchronization between cpus (not as it fills
each dinky page) and in more flexible buffering semantics.  As written
there is no support for cyclic lists of pages rather than streaming nor
are a huge amount of pending pages allowed.  debugfs masks the mode of
the file so it appears to be a regular file, but that'd be trivial to
fix if this is methodology is useful.

Thoughts?  I, for one, am tired of writing throw-away per-cpu tracing
patches ;)