Delegating printk work to UART interrupt

Arun KS getarunks at gmail.com
Mon Jul 20 00:04:16 EDT 2015


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,
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/printk/printk.c?id=5874af2003b1aaaa053128d655710140e3187226

Its not changing console printing through UART to interrupt mode. But
minimizes the time interrupts being disabled on printk().

Thanks,
Arun



>
> --
> Alexander <alexhoppus111 at gmail.com>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150720/198b65bf/attachment.html 


More information about the Kernelnewbies mailing list