[Click] To/FromUserDevice enhancements

[Cliff Frey]

https://github.com/clifffrey/click/commit/7ccadf37b971e43ef8b6d56b2ed6220389ef173d

I have made a bunch of changes to both ToUserDevice and FromUserDevice.
 These elements now provide an easy way to get a pcap file out of click when
it is running in the kernel, as well as other options for communicating with
click if using linux's networking stack (ToHost/FromHost) is not desired.

I'd appreciate any feedback, especially if anyone has an elegant idea to
handle the click-unload cases (which I believe can cause kernel panics
today).

Cliff

commit 7ccadf37b971e43ef8b6d56b2ed6220389ef173d
Author: Cliff Frey <cliff at meraki.com>
Date:   Wed Mar 2 11:01:59 2011

    (To/From)UserDevice: cleanups, fixups, features

    ToUserDevice is now much more configurable, supporting multiple
encapsulation
    types (none, pcap, and length-delimited).  It also supports acting like
a
    datagram socket, where each read corresponds to one packet, or like a
streaming
    socket, where every byte will definitely be returned, but there is no
obvious
    cutoff between one packet and the next.

    FromUserDevice now depends on an existing ToUserDevice element, and the
same
    character device is used for both directions of communication.

    Here is one example usage of ToUserDevice:

      mknod /dev/click_user0 c 241 0
      cat > /click/config <<EOF
        is :: InfiniteSource(LIMIT 10)
        -> UDPIPEncap(1.1.1.1, 11, 2.2.2.2, 22)
        -> EtherEncap(0x0800, 00:01:02:03:04:05, 00:01:02:03:04:06)
        -> tud :: ToUserDevice(0, ENCAP pcap, BLOCKING false)
      EOF
      cat /dev/click_user0 > /tmp/foo.pcap
      tcpdump -n -r /tmp/foo.pcap

    Another would just be to use both ToUserDevice and FromUserDevice to
create a
    file that could be treated like a UDP socket to communicatie with click
(but
    without using linux's networking stack).

    I believe that I fixed the poll() functions for both elements... but I
am not at
    all confident that they are really bug-free.

    I believe that ToUserDevice has multiple potential bugs involved with
unloading
    the config and/or removing the click kernel module.  The fact that
dev_open
    stores a pointer to the element object seems quite unsafe, as if the
config is
    unloaded, the object would be freed.  Also, the fact that the
file_operations
    object points to functions in the kernel module means that it is
necessary to
    make sure that all file handles are closed before unloading the kernel
module,
    and I don't believe that this is done today.  My gut feeling is that the
right
    fix for both problems is to actually make cleanup() block until all
outstanding
    file handles are closed.