quoted

Would it be difficult to make the lock per fbdev thing?  If the
CPU/accelerator clash is the only reason for the global lock, we can
certainly remove that for hardware which doesn't have that kind of
problem, can't we?

There could indeed be separate locks per fbdev. But the global console lock
(console_lock) would still be there. It is needed because the console subsystem
is not re-entrant (yet). Since fbdev is called from the console subsystem, it
runs under the same lock (i.e. with interrupts disabled).

I will be testing for re-entrant ability next week with code I have in
CVS. Their should be a semaphore for each struct console. Also their
should be a semaphore for each VT where on semephore is shared between the
VT console and struct console. Why a semephore. Eventually we will run
into hardware that runs only by interrupts. So a hardware independent why
to lock the console system is needed.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/