ed at 80386.nl
Mon Aug 24 17:40:51 UTC 2009
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
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.
It's not like the spin locks are held for an insane amount of time, but
still, especially when doing things like scrolling the screen buffer, I
think using default mutexes would be a lot better.
I was thinking, in theory I'd only need to lock the first window of my
console device instances with spin locks, because the other windows will
never interact with the kernel message/debug console. I was thinking
about locking the mutexes and using their lock classes to call the
appropriate lock routine, but looking at the source, something tells me
this won't work:
| lock_spin(struct lock_object *lock, int how)
| panic("spin locks can only use msleep_spin");
So basically I'm sending this message to ask what I should do here. Is
there a more elegant way to solve this?
Ed Schouten <ed at 80386.nl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090824/3f1a6ba3/attachment.pgp
More information about the freebsd-arch