[linux-fbdev] Re: [ANN] IRQ Latency tool 0.1.3 release.

[James Simmons]

> > 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 at 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/