Re: ahc/ahd locking

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Some questions:
:
:1. I'm not quite understanding the interaction w/ bus_setup_intr and the
:serializer.  Is the usage correct in ahd_platform_intr, or should I be
:using lwkt_serialize_handler_enable somewhere?

    Take a look at the if_em.c code, that's the cleanest serializer-using
    code we have.  (/usr/src/sys/dev/netif/em/if_em.c).  Note that the
    network interface code acquires the serializer for if_em.c (as well as
    the interrupt subsystem), but the device entry points do not.

    You pass the serializer to bus_setup_intr()... I suggest having just
    one serializer per interrupt source (I'm not sure how that works with
    ahc/ahd)... but its the easiest way to do it.  If you do that then
    the kernel interrupt code will automatically acquire the serializer before
    calling your interrupt handler and release it when yo ureturn.

    All calls to your interrupt handler will be serialized for you, you don't
    have to make any additional calls to the serializer.  You do have to 
    make sure that you do not try to acquire the serializer AGAIN from your
    interrupt code (you will deadlock against yourself).  If the adaptec
    code isn't condusive to this type of thing you can release the 
    serializer in the interrupt code and then reacquire it before returning.
    But I recommend that the code be structured so you don't constantly
    get and release the serializer in the code paths that run from the
    interrupt handler.

    All calls into the device driver via device entry points will NOT be
    serialized.  You have to acquire the serializer in those cases.  Similar
    to what if_em does.

:2. How should the tsleep()s be handled?
:
:--Peter

    You can't msleep with the serializer :-).  That's for spinlocks only.
    However, it *IS* ok to hold a serializer lock through a context switch,
    as long as you don't deadlock against something else by doing that.  It
    is not recommended however... only do it if the related code must not
    be broken. 

    If you need to roll your own interlocked msleep-style sleep, take a look
    at how msleep is implemented in the kernel and roll your own that takes
    a serializer lock.  It's very simple, in fact.

						-Matt