Delegating printk work to UART interrupt

[Alexander]

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?

Thank you.

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


-- 
Alexander <alexhoppus111 at gmail.com>