Bruce Evans brde at
Tue Aug 25 14:23:03 UTC 2009

On Mon, 24 Aug 2009, Marcel Moolenaar wrote:

> On Aug 24, 2009, at 10:40 AM, Ed Schouten wrote:

>> As some of you may already know, I'm writing a console driver for
>> FreeBSD in my Perforce branch (newcons). What I don't like about console
>> devices, but cannot be avoided, is that certain pieces of code need to
>> be protected by spinning mutex, instead of default mutexes. This is

Certain pieces cannot be protected by any mutex.

>> because things like the terminal emulator need to be protected from
>> concurrent access, which is likely to happen when printf() by the kernel
>> and a write() on a TTY by a userspace process happen at the same time.

These are the easy cases.  The interesting cases are synchronous i/o
in panic and debugger traps (NMI and non-interrupt related traps can
also preempt even a spin mutex, but these shouldn't do console i/o
except via panic).  Mutex locking cannot work in these cases.  At best
you can ignore the mutex and proceed.  In fact, no exclusive or shared
locking can work.  Atomic operations and reentrant code can work.
Hardware and i/o operations to it are fundamentally non-reentrant, so
console drivers must arrange for the i/o to clobber the hardware state
as little as possible.

Once you have made i/o in debugger traps work, other cases are trivial.
Debugger trace traps are especially useful for testing reentrancy,
since they are deterministic and occur on every instruction.  Races
that rarely occur in practice are easy to detect by single-stepping
(with i/o) through every instruction in upper-level device
initialization and i/o routines.

> I would approach the problem differently: decouple printf() in the
> kernel from anything to which we have a TTY attached. Instead, look
> at printf() as a means to write to the message buffer only. Echoing
> things that go into the message buffer to the console becomes 1)
> optional (yay!), and 2) something you can do by going through the TTY
> layer (use a kthread or use a process [syslog]).

This is already implemented (TIOCCONS ioctl), but cannot work for serious
debugging or panics, since it cannot provide synchronous i/o when it is
most needed.


More information about the freebsd-arch mailing list