From owner-freebsd-current Sat Oct 13 9:39:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 9EFC237B405 for ; Sat, 13 Oct 2001 09:35:32 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 15sRlE-00066G-00; Sat, 13 Oct 2001 18:35:40 +0200 From: Sheldon Hearn To: Dag-Erling Smorgrav Cc: Doug Barton , freebsd-current@FreeBSD.ORG Subject: Re: Strike three, you're out In-reply-to: Your message of "13 Oct 2001 16:06:16 +0200." Date: Sat, 13 Oct 2001 18:35:40 +0200 Message-ID: <23451.1002990940@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 13 Oct 2001 16:06:16 +0200, Dag-Erling Smorgrav wrote: > It's very difficult to fix. The problem is that printf() is used in > the strangest parts of the deepest bowels of the kernel, but if a > process grabs the console with TIOCCONS, printing something to the > console causes the process that grabbed it to be woken up, which is a > bad idea if, for instance, printf() was called from within mi_switch() > (as is the case for those "microuptime() went backwards" messages). This sounds analogous to the problems one encounters with printf(3) (library function) inside signal handlers. Perhaps the analogous solution is to be more careful about the use of printf() in the kernel? Perhaps a similar approach as is used in userland signal handlers should be taken, where a flag is set and later the printf() is performed conditional on the state of the flag? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message