lkml.org 
[lkml]   [2001]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: console spin_lock

> heh.
>
> I'm actually planning on grabbing console_lock and thoroughly strangling
> it

Ha Ha!!

> - Use a semaphore for serialisation.

I think this would be the best solution as well.

> - For printk in interrupt context, grab the
> semaphore (yes, you can do this).

Don't forget about the idle task also. How is this done? By reintializing
the semaphore.

> - If it couldn't be acquired from interrupt context,
> buffer the text in the log buffer and return. The text will be
> printed by whoever holds the semaphore before they
> drop it.

By you saying couldn't be acquired from interrupt context do you mean
from a process context or do you mean it failed to aquire it while in
the interrupt context?

> - Special "system booting" mode which bypasses all this
> stuff.

This wouldn't be to hard to do for VTs using the fact that keybaords
are not initialized right away. As for serial consoles well that is
another story. Of course we could have this flag set/cleared in
start_kernel.

> - Special "oops in progress" mode which just
> punches through everything.

You already developed the framework for this.

> - Get rid of the special printk buffer - share the
> log buffer. (Implies writes to console
> devices will be broken into two writes when they
> wrap around).
> - Teach vsprintf to print into a circular buffer
> (snprintf thus comes for free).

> - Get rid of all the printk deadlock opportunities (fourth
> attempt).

Good luck.

> - Get rid of console_tasklet. Do it in process context callback
> or just do it synchronously.

What about multidesktop systems? I have vgacon and mdacon working fine
along each other. Each one has their own tasklet to allow them to work
independent of each other. Meaning no race condition when both VC switch
at the same time.

> Assumption:
> - Once the system is up and running, it's always safe to
> call down() when in_interrupt() returns false - probably
> not the case in parts of the exit path - tough.

Don't forget the idle_task case as well. exit path?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.111 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site