Subject: Re: spl/ipl stuff
To: Bill Studenmund <firstname.lastname@example.org>
From: Chris G. Demetriou <email@example.com>
Date: 07/04/1997 22:22:10
> 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
> 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
> > 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
(2) see spl(9) for some not-unreasonable spl*() documentation,
including ordering information.