Ben Greear <greearb@xxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
