>Could some kind soul (perhaps he who claimed to be working on a
>device driver doc) email me some generals about disabling/enabling
>interrupts?  specifically: is it always best to use splXXX() or
>are there other forms like "disable_intr()" (used in isa/cy.c) which
>are better under some circumstances?  

Well, that would be me (unfortunately, I haven't had much time to work on
that doc :-( ).

I feel generally it's best to use splXXX() for interrupts.  These set different
priority levels so interrupts that have a higher priority (for example, network
interface interrupts) can be serviced.  Since your interrupt routine happens
at whatever level you set up for it, using spltty (for example) to protect
critical routines will work fine (that's assuming you registered your interrupt
routine to happen at IPL_TTY).

I believe that disable_intr() is an i386-specific thing.  On the i386 it will
execute a machine language instruction that turns off ALL interrupts.  This
should only be used where it's absolutely necessary.  For example, the Gravis
Ultrasound driver I'm working on uses disable_intr() in the attach routine,
as when you're configuring the IRQ's on the Ultrasound there can be no other
traffic on the I/O bus.

>how atomic are assignments?  can "a = 0" be interrupted?  how about
>cp = p -> foo?  

I believe that's machine-specific.  I think "a = 0" would not be interruptable,
but "cp = p->foo" might be, depending on how many instructions it generated.

It's probably best to surround such code with a splXXX()/splx() pair to be
safe.

>In the com.c driver, fairly sweeping segments of code are enclosed in
>spltty()/splx(); was this a quick and dirty thing, or a reasonable use?

I don't know exactly which segments you're referring to, but if you have a
bunch of code that would be thrown off by an interrupt then it would be
reasonable (and I would guess that com.c is).

--Ken