Re: Serial console and interrupts latency.

[Sergey Organov <sorganov@gmail.com>]

Russell King - ARM Linux admin <linux@armlinux.org.uk> writes:

> On Tue, Apr 14, 2020 at 12:50:49PM +0300, Sergey Organov wrote:
>> Russell King - ARM Linux admin <linux@armlinux.org.uk>:
>> > Correct, and what I said back then still applies - and more.
>> 
>> What bothers me is "we have no real option..." part of this, as it's rarely
>> happens to be the case.
>
> I don't see you coming forward with a solution beyond "let's revert
> the commit" or "let's comment out the lock" - neither of which are
> an option for mainline kernels.

I didn't suggest to revert the commit, as it obviously solves real
problem. I asked if and why the lock is needed on non-SMP targets, but
either I didn't get a reply or missed it, sorry.

I mean everything I said was to get some help rather than to spread
useless critics or even insults.

>
> Until *you* do, since you obviously have better ideas, "we have no
> real option".

I'm in the process of making myself familiar with the internals of
printk machinery to find generic solution, but if nobody else actually
cares, I'll stop bothering you guys with my questions.

Do I get it right that you still think there are no sensible options but
to disable interrupts for ages? If so, it would greatly reduce my drive
to find one... or maybe the other way round, but it'd be nice to know
either way.

> But, as I've said, one of the *important* characteristics of serial
> console is that it is synchronous with the kernel, so it can be
> relied upon to get complete messages out if the kernel crashes after
> a printk() has been executed, and that must not be lost.

Do I get it right that it's covered by the 'oops' case, or are there
hidden pitfalls as well?

Thanks,
-- Sergey