1.  Is there at present any good way to do a "uiopeek", that is, to
    copyin some data described by a uio, look at it, and /then/ decide
    whether to update uio_{iov{,->base,->offset},resid,offset}?

    application: whether I can afford at the moment to buffer the next
    packet in a write(2) request depends not just on its size but on
    its content.  If I can't take it just now, I'd like the write(2) state
    (on WOULDBLOCK return or interrupted block) to reflect that it hasn't
    been taken, so that the natural behavior of the user process will be
    to present it again with the next write(2).

    Is this an outlandish behavior to specify? (It does seem to need one
    special case, in that to preserve the usual semantics of select/poll,
    the /first/ packet in a write would have to be accepted if anything
    could, regardless of the content test.)

2.  Are the hashinit/hashdone functions in kern_subr.c intended to be
    generally usable kernel API?  Should there be a man 9 page for them?

-Chap