> > > > > There is a concern about getting efficient log report, > > > > > especially when looking at CI issues. > > > > > > > > +1. > > > > The current solution with logs is a real pain. > > > > > > Are you guys talking about problems with > > > app/test/sample_packet_forward.* David reported? > > > Or some extra problems arise? > > > > The problem will arise each time an app is misbehaving. > > That's going to be a recurring problem in the CI.
It is still not clear to me why it is going to be a recurring one? Ok, right now we have some test-cases that are misbehaving unintentionally. So we need to fix them. I admit that it might be a pain, but it still looks like a one time job to me. With new test-cases we should be able to catch such misbehaving at patch submission stage (by checking then logs). I guess there might be some test-cases that misbehave intentionally - some negative test-cases for error-condition checking etc. But for them error message in the log and error return value seems like a right thing, no? Again I expect such test-cases do erroneous rx/tx_burst just few times (not dozens or hundreds) so they shouldn't pollute log too much. So, what I am missing here? > > > > One thing that could be done is compiling with asserts in CI, and let > default build not have those asserts. Agree, log+assert seems like a good alternative to panic() for me. > Otherwise, logging once should be enough (I have a patch for this latter > idea). I understand the intention, but I am a bit sceptical about that one: it is quite often people don’t pay much attention to single log message.
