You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both emulated uart and our additional qemu logging goes to stderr. This is unbuffered. It is fairly common for some messages, e.g. DMA logging, to occur while Canon is logging. This causes interleaved output that makes comparing the results of a test run difficult.
Ideally we would be able to know the difference between our logging and Canon output, while also being able to reconstruct order of events. We could log each to separate files, but that makes reconstruction of order hard. We could wrap our output in magic prefix/suffix (a little ugly). We could use some kind of event store (DB, json?) - line by line for uart, fprintf based for our additional logging?
The text was updated successfully, but these errors were encountered:
The old system seems to use -serial file:somefile.log with qemu, which I assume strips out any qemu-eos direct fprintf() logging. That's probably workable for now but not ideal.
Both emulated uart and our additional qemu logging goes to stderr. This is unbuffered. It is fairly common for some messages, e.g. DMA logging, to occur while Canon is logging. This causes interleaved output that makes comparing the results of a test run difficult.
Ideally we would be able to know the difference between our logging and Canon output, while also being able to reconstruct order of events. We could log each to separate files, but that makes reconstruction of order hard. We could wrap our output in magic prefix/suffix (a little ugly). We could use some kind of event store (DB, json?) - line by line for uart, fprintf based for our additional logging?
The text was updated successfully, but these errors were encountered: