> There is a recomended order, well a dependancy list. I think it's in
> the red book, and it's burried in the code, too. But it's burried
> deep, I'll admit. :-)

take a look at /sys/arch/i386/isa/isa_machdep.c, starting around line
280.


> As I've debugged the serial drivers for the mac, I've run into this
> problem. You're right that printf's at interrupt time are bad. The
> 8530 serial driver (zsc & zstty & friends) will only do logging in a
> routine which sets spltty.

They should be bad because they require polling output, not because of
the spl*() functions that they use.

the spl*() functions in NetBSD are largely defined to be "raise IPL to
...", rather than "set IPL to ...".  -current source as of a few days
ago indicates that the mac port gets this wrong.  For an example of an
m68k port which does it (more, perhaps completely; i don't know)
correctly, take a look at the hp300 port.  For the definition of the
semantics see spl(9).


> A number of the spl level stuff is a form of blanket resource lock. spltty
> locks ALL the tty queues. But a process (or an interrupt handler..) only
> needs to worry about access to one particular tty queue. Thus the printf's
> will probably work if they are touching one queue when the process which
> asserted spltty is touching another.

Uh, kernel printfs aren't supposed to be pushing data on to tty
queue, they're supposed to be stuffing the data directly out the
serial port.


> > If the above is true and different ports use different spl orderings then
> > presumably use of printf()/log() in the interrupt routines of generic drivers
> > (or anything that can be called by them) is a Bad Thing (tty code excepted).
> 
> Documenting things better is good.  [ ... ]

(1) printf()/log() should be safe to use in generic drivers' interrupt
routines.

(2) see spl(9) for some not-unreasonable spl*() documentation,
including ordering information.


cgd