Re: console spin_lock

From: Andrew Morton (andrewm@uow.edu.au)
Date: Wed Jan 17 2001 - 08:49:37 EST


James Simmons wrote:
>
> Some time ago a intel i810 framebuffer driver was written. It only worked
> for 2.2.X. With 2.4.X a spinlock is used in the upper layers of the
> console system. Sooner or later we are going to run into the situtation
> where we will have graphics hardware which has no vga core and wih be
> purely DMA/irq based (i.e i810). In this case using the current
> console_lock will block the driver itself. I have thought about a
> possible solution. A semaphore can't be used since their is a spin_lock
> in the console_softirq. Since this is in a interrupt context a
> semaphore can't be used. Another idea was to do a
>
> void get_vc_lock(void)
> {
> while (test_and_set_bit(0, &vc_var))
> ;
> }
>
> Any better ideas?
>

heh.

I'm actually planning on grabbing console_lock and thoroughly strangling
it
next week. It can block interrupts for up to a second. That just isn't
civil.

- Use a semaphore for serialisation.
- For printk in interrupt context, grab the
  semaphore (yes, you can do this).
- 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.
- Special "system booting" mode which bypasses all this
  stuff.
- Special "oops in progress" mode which just
  punches through everything.
- 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).
- Get rid of console_tasklet. Do it in process context callback
  or just do it synchronously.

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.

Anyway, that's the thoughtware. Sound sane?

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



This archive was generated by hypermail 2b29 : Tue Jan 23 2001 - 21:00:15 EST