cvs commit: src/sys/amd64/amd64 genassym.c src/sys/arm/arm genassym.c src/sys/i386/i386 genassym.c src/sys/ia64/ia64 genassym.c src/sys/kern subr_prf.c tty_cons.c src/sys/powerpc/powerpc genassym.c src/sys/sparc64/sparc64 ...

[Bruce Evans]

On Wed, 1 Nov 2006, John Baldwin wrote:

> On Wednesday 01 November 2006 04:35, Pawel Jakub Dawidek wrote:
>> On Wed, Nov 01, 2006 at 04:54:51AM +0000, John Birrell wrote:
>>> jb          2006-11-01 04:54:51 UTC
>>> ...
>>>   Log:
>>>   Add a cnputs() function to write a string to the console with
>>>   a lock to prevent interspersed strings written from different CPUs
>>>   at the same time.
>> ...
>> What I'd like is a global printf_lock which will allow me to put many
>> separate printfs under it and be sure it won't be messed up by other
>> CPUs. Having it recursive could also eliminate the need for per-CPU
>> buffers, as I don't think we care about performance here.
>>
>> What do you think?
>
> Because printf is used for things like panics, I think it needs to be as
> robust as possible.  I think adding a larger lock like you request would make
> it too fragile.

It's already quite fragile.  Deadlocks seem to be possible in at least
the i386 NMI handler now (not just for panics, and even for one type
of debugger entry), and were already possible due to similar spinlocking
in some console drivers.  (Note that NMIs defeat the usual deadlock
avoidance method of disabling interrupts on the current CPU.) Most
other deadlocks for printf() in panic() seem to be prevented by the
bug that panic() doesn't stop other CPUs.

Bruce