Re: Firmware debugging patches?

[Kalle Valo <kvalo@qca.qualcomm.com>]

Ben Greear <greearb@candelatech.com> writes:

>>> Perhaps the time-stamp is good enough?  I don't see a need for
>>> a uuid, but perhaps I am missing something?
>>
>> UUID is supposed to be unique. If we use walltime there's no guarantee
>> that the clock is correct and if we use local_clock() (my preference) it
>> will be reset after every boot.
>>
>> I just think using something like UUID is more robust. Especially if one
>> implements an automatic crash dump collector from thousands of deployed
>> APs, having an UUID makes it a lot easier to manage.
>
> I can add since-boot timestamp as well.  Time-since-boot is less likely
> to be unique than wall-time, and for systems that do have proper wall-time
> clock configured, I think that provides some useful info.  (Would be interesting
> if all APs in a stadium crashed near the same time, for instance.)
>
> I was thinking we should not add a MAC to the dump, for privacy concerns,
> but whatever user-space tools gather the dump could add MAC if user perfers.

The MAC addresses can be extracted from the target memory anyway so I
don't see harm from including that in the dump. Is it even possible to
address all privacy issues when dealing with firmware dumps?

> With time-of-day, time-since-boot, and MAC, each dump should be unique.

But I would like to easily match from kernel log that the crash dump
matches with log. uuid would provide that in a simple way (check that
the uuid in the log matches with the uuid in the dump). What's so bad
from using uuid?

-- 
Kalle Valo