Matt and I have exchanged a couple of messages off-list in addition to
the on-list traffic.  I think we've reached agreement on most issues.
The list I have is that:

1.  Ideally, one or other of kcont and generic-softints, but not both;

2.  The functionality of kcont is richer than generic-softints. We could
    reworked generic-softints to be a full replacment for kcont, but it'd
    look (modulo Matt's other points) much like kcont does now.

3.  Most (if not all) current uses of generic softints could be replaced by
    kcont(9) with the kcont object  allocated as a sub-field of some other
    long-lived memory (such as a device softc).   kcont should aqcuire a static
    initializer macro to make this task easier.

4. IPL_*. issues. kcont  already has separate queues for each currently-supported
   deferred IPL. The  semantics between them, and the misuse of IPL_* values,
  (the comparison) needs to be cleaned up. Other ideas (such as  ping-ponging
   already-allocated kconts from one queue to another)  should be documented, or abandonded.

5.  Since there's no example code in the tree, the design intent and *all*
    planned/envisaged uses, need to be  spelled out.

6.  Matt strongly wants to restrict allocation of kconts to thread-safe context.
    I still have private uses for allocating kconts truly on-the-fly.
    We need to reach closure there. 

Matt, is that right? Did I forget anything?