Support FD taps in #I on data files
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 3 Aug 2015 17:14:02 +0000 (13:14 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 28 Sep 2015 19:14:00 +0000 (15:14 -0400)
commit0eda42f9d0d5091c0195e6db82f8f1574ec09aab
tree59f4f140cce4796ad7663c992a277123c3a6c74f
parent2c165333d6db47195d79f22798a3eb6ac5279e80
Support FD taps in #I on data files

With this commit, users can put FD taps on data files (e.g.
/net/tcp/0/data).  We'll get a callback from qio whenever a READABLE,
WRITABLE, or HANGUP filter occurs.  fire_tap() will send an event, if
the tap filter matches the event.

Notice that we ignore certain events on the 'wrong' queue.  For
instance, we don't care when the wq becomes READABLE.  In fact, #I is
responsible for that event.  It'd be like firing a tap to tell someone
that they just performed a write and a packet is ready to move *deeper*
into the network stack.

Another thing to be aware of is qio bypass.  This feature allows a queue
to have its write method bypassed.  Check out qbwrite().  This means
that some protocols with bypass might not be tapable.

One user of bypass is UDP: its wq has a bypass set to udpkick().  Since
UDP's wq bypasses the usual qbwrite(), it will not receive wake
callbacks when the write queue is drained and becomes *readable*.  But
we don't care about those anyways; we care when the write queue becomes
writable.  So in this case, there's nothing to worry about, but there
could be issues in the future.  Stay alert.

As a side note, udp's write bypass also means that the Qnonblock setting
is not necessarily checked or honored.  If udpkick decides to block,
then too bad for the conversation's non-blocking status.  Bypass methods
ought to honor those settings.  In this case, udpkick doesn't block
within the protocol processing (like TCP does), so it's not a concern.
kern/include/ip.h
kern/src/net/devip.c