Re: + printk-print-initial-logbuf-contents-before-re-enabling-interrupts.patch added to -mm tree

[One Thousand Gnomes]

> Possibly, but I fear we'd incur the wrath of Alan after reading that other
> thread. Having a CONFIG_ option or similar to control the amount of printing
> we do is very similar to the command-line option Jan proposed in his series.

I've nothing against a configuration option, and having a printk that
queued most stuff to the serial IRQ handler on overflow and a boot option
of printk=synchronous for debug work would be awesome in my book. Many end
production boxes don't give a toss about losing the odd bit of data they
just need to shift the logs somewhere for filing.

All these "clever" approaches just seem to me to be ever more convoluted
attempts to fail to deal with the simple reality that if you put more
down the sewage pipe than fits it has to overflow somewhere.

Our tty drivers have a fifo, our tty drivers have an IRQ driven write
operation. It seems silly to be adding magic to solve the problem rather
than just using it (and in turn getting a ton of other consoles for free,
and being able to take GregKH's current usb console hack out)

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/