{"shas":[["eb2b54eeba79ed088a812910b1c7f2f43249e762","5eaece5f08370e3fed539bf7c0bff5d813a27ed3@meraki.com","(To/From)UserDevice: cleanups, fixups, features\n\nToUserDevice is now much more configurable, supporting multiple encapsulation\ntypes (none, pcap, and length-delimited).  It also supports acting like a\ndatagram socket, where each read corresponds to one packet, or like a streaming\nsocket, where every byte will definitely be returned, but there is no obvious\ncutoff between one packet and the next.\n\nFromUserDevice now depends on an existing ToUserDevice element, and the same\ncharacter device is used for both directions of communication.\n\nHere is one example usage of ToUserDevice:\n\n  mknod /dev/click_user0 c 241 0\n  cat > /click/config <<EOF\n    is :: InfiniteSource(LIMIT 10)\n    -> UDPIPEncap(1.1.1.1, 11, 2.2.2.2, 22)\n    -> EtherEncap(0x0800, 00:01:02:03:04:05, 00:01:02:03:04:06)\n    -> tud :: ToUserDevice(0, ENCAP pcap, BLOCKING false)\n  EOF\n  cat /dev/click_user0 > /tmp/foo.pcap\n  tcpdump -n -r /tmp/foo.pcap\n\nAnother would just be to use both ToUserDevice and FromUserDevice to create a\nfile that could be treated like a UDP socket to communicatie with click (but\nwithout using linux's networking stack).\n\nI believe that I fixed the poll() functions for both elements... but I am not at\nall confident that they are really bug-free.\n\nI believe that ToUserDevice has multiple potential bugs involved with unloading\nthe config and/or removing the click kernel module.  The fact that dev_open\nstores a pointer to the element object seems quite unsafe, as if the config is\nunloaded, the object would be freed.  Also, the fact that the file_operations\nobject points to functions in the kernel module means that it is necessary to\nmake sure that all file handles are closed before unloading the kernel module,\nand I don't believe that this is done today.  My gut feeling is that the right\nfix for both problems is to actually make cleanup() block until all outstanding\nfile handles are closed.\n\nSigned-off-by: Cliff Frey <cliff@meraki.com>","Cliff Frey"]],"ref":"refs/heads/master","size":1,"head":"eb2b54eeba79ed088a812910b1c7f2f43249e762","push_id":34147535}