On 9/3/20 10:30 AM, Jiri Pirko wrote:
Thu, Sep 03, 2020 at 05:58:42PM CEST, snel...@pensando.io wrote:
True, they aren't "needed" for operational purposes, but they are rather
useful when inspecting a system after getting a report of bad behavior, and
I don't think it is nice to pollute dmesg with any arbitrary driver-specific
messages.
since this should be seldom performed there should be no risk of filling the
log. As far as I can tell, the devlink messages are only seen at the time
the flash is performed as output from the flash command, or from a devlink
monitor if someone started it before the flash operation. Is there any other
place that can be inspected later that will indicate someone was fussing with
the firmware?
Not really, no. But perhaps we can have a counter for that. Similar to
what Jakub suggested for reload.
When we need to debug a complaint about a firmware load, I want to be
able to find out what fw file the user actually tried to load, and maybe
were there other broken load attempts before that. If there was
something that broke in the download, it would be nice to know when -
beginning? 4k bytes in? near the end? A counter might show a number
of load attempts, but no context as to when, what file, or what else was
going on around the same time.
sln
