DragonFly HEAD update (hammer, kqueue, crypto)

[Matthew Dillon]

    The last week or two we've had some instability in the head branch.
    Most of these problems should now be fixed.

    The problems are associated primarily with HAMMER and the kqueue
    work.

    HAMMER received some new assertions to catch buffer overlaps and,
    well, they started unexpectedly asserting.  Some issues with
    HAMMER's clustered read-ahead were revealed and should now be
    fixed.  The assertions could reveal additional bugs in the future,
    I am keeping them in to try to find and fix as many bugs as possible.

    Kqueue has begun using the kq_token and no longer uses the MP
    lock.  The kqueue backend to select/poll is correct but fragile
    code and it expects the kqueue subsystem to work properly.  When
    it doesn't the backend tends to loop, locking up the system.

    In addition to fixing several races that were revealed I have
    also added a limit counter that will panic the system instead
    of letting it livelock if the situation comes up again.

    Finally, since all I/O event handling uses kqueue internally now
    there is quite a bit of new code in various drivers that sometimes
    leads to panics due to bugs.  These are being fixed as they come up.

    --

    The default crypto algorithms committed last week by Alex for block
    devices are now compatible with linux and shouldn't change much from
    now on.  His more recent commits of additional crypto algorithms are
    still considered very experimental and may change.

    A great deal of work has gone into managing the I/O pipeline through
    dm_target_crypto and dm_target_stripe and has resulted in a
    significant improvement in performance.

						-Matt