Delegating printk work to UART interrupt
alexhoppus111 at gmail.com
Wed Jul 22 01:38:14 EDT 2015
Hi Arun KS,
Actually, i already saw this one and something similar were tested. I just trying
to figure out the reasons why generic kernel layer (console_unlock) implemented
in such way: i.e. why it accounts on immediate busyloop printing? Is it reliable to
defer such printing to UART interrupts?
On Mon, 20 Jul 2015 09:34:16 +0530
Arun KS <getarunks at gmail.com> wrote:
> Hello Alexander,
> On Sat, Jul 18, 2015 at 11:23 AM, Alexander <alexhoppus111 at gmail.com> wrote:
> > Hi!
> > When i checked how kernel printing works, i mentioned that it takes
> > messages
> > from log_buffer in console_unlock and gives it to call_console_drivers ->
> > ...
> > -> some uart bsp function. Basically, as i see this BSP realization tries
> > to flush all message chars in busyloop ... so it waits until FIFO_NOT_FULL
> > bit will
> > be dropped by UART and it will be able to push the next byte.
> > Basically, as i see userspace printing do something different. It puts
> > N_FIFO_BYTES
> > and exits, next, when FIFO will be freed - interrupt will be generated, and
> > other characters will be put into UART FIFO.
> > Can we do something similar for kernel printing? i.e. do not busyloop
> > sending char
> > after char, but put N_FIFO chars and flush other in interrupt. When panic
> > will occur
> > we can do busyloop printing again. Is it reliable? Suppose we have several
> > cores.
> > Thank you.
> What about trying this patch,
> Its not changing console printing through UART to interrupt mode. But
> minimizes the time interrupts being disabled on printk().
> > --
> > Alexander <alexhoppus111 at gmail.com>
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Alexander <alexhoppus111 at gmail.com>
More information about the Kernelnewbies