On Thu, 11 May 2023 14:20:51 +0200 Markus Armbruster <arm...@redhat.com> wrote: [..] > > > > In my opinion the best way to deal with such situations would be to > > abort() in test/development and log a warning in production. Of course > > Understand, but... > > > assert() wouldn't give me that, and it wouldn't be locally consistent at > > all. > > ... nothing behaves like that so far. >
I understand. And I agree with all statements from your previous mail. > Let's try to come to a conclusion. We can either keep the current > behavior, i.e. abort(). Or we change it to just print something. > > If we want the latter: fprintf() to stderr, warn_report(), or trace > point? > > You are the maintainer, so the decision is yours. > > I could stick a patch into a series of error-related cleanup patches I'm > working on. I would gladly take that offer. Given that we didn't see any crashes and thus violations of assumptions up till now, and that both the kvm and the qemu implementations are from my perspective stable, I think not forcing a crash is a good option. From the options you offered, warn_report() looks the most compelling to me, but I would trust your expertise to pick the actually best one. Thank you very much. > > > [*] I'm rather fond of the trick to have oopsie() fork & crash. I never thought of this, but I do actually find it very compelling to get a dump while keeping the workload alive. Especially if it was oopsie_once() so one does not get buried in dumps. But we don't do things like this in QEMU, or do we? Regards, Halil
