Re: [PATCH] panic.c: export panic_on_oops

Ingo Molnar
2009-10-12T13:25:17Z

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > See my reply to David Woodhouse, i think we should add support for
> > buffering in kernel/printk.c and that would both fix your problems,
> > would simplify the driver (significantly!) and would expose the
> > generic buffering capability to other console drivers as well.
>
> Buffering printk in general is bad. [...]

The general (and default) case would be 0 buffering - i.e. finegrained
per line calls to ->console_write().

This is the common case indeed, we want to get console output out as
soon as possible and as finegrained as possible - as we dont know when a
failure mode removes our ability to print anything else.

My argument is that instead of a complicated dance of workqueue versus
non-workqueue printk support in the MTD code in drivers/mtd/mtdoops.c,
this should be done at the generic console level.

It's not hard, nor complex if done at the right level, nor does it
impact the regular zero-buffering codepath in a significant way - and
the end result would be a significantly simpler (and, in turn, more
robust) MTD printk driver.

I care about this because i still havent given up hope that the company
you are working for will finally give us some permanent storage in the
CPU itself, so that we can have cross-reboot printk buffering ;-) If
that storage is in the form of Flash, then buffering (to optimize write
cycles) is probably a must.

> [...] Given a driver needs only to provide about 6 lines of code using
> a kfifo is it really that hard for the odd code that wants to buffer
> to do that ?

Avoiding a workqueue in printk is about the critical path of failure and
about complexity in general.

I dont see how kfifo helps here much - kfifo is really just a relatively
simple dynamic memory buffer abstraction - while most of the complexity
here is elsewhere. Could you explain what you meant with kfifo here
please?

Ingo