Re: git: fc90f3a28145 - main - ktrace: Increase precision of timestamps.
Date: Mon, 18 Jul 2022 11:11:40 UTC
On Mon, Jul 18, 2022 at 01:07:24PM +0300, Konstantin Belousov wrote: > On Sun, Jul 17, 2022 at 09:27:09PM +0300, Dmitry Chagin wrote: > > On Sat, Jul 16, 2022 at 04:52:28PM +0300, Konstantin Belousov wrote: > > > On Sat, Jul 16, 2022 at 09:50:02AM +0000, Dmitry Chagin wrote: > > > > The branch main has been updated by dchagin: > > > > > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=fc90f3a28145872afb7106d391bc922572eb2b71 > > > > > > > > commit fc90f3a28145872afb7106d391bc922572eb2b71 > > > > Author: Dmitry Chagin <dchagin@FreeBSD.org> > > > > AuthorDate: 2022-07-16 09:46:12 +0000 > > > > Commit: Dmitry Chagin <dchagin@FreeBSD.org> > > > > CommitDate: 2022-07-16 09:46:12 +0000 > > > > > > > > ktrace: Increase precision of timestamps. > > > > > > > > Replace struct timeval in header with struct timespec. > > > > To differentiate header formats, add a new KTR_VERSIONED flag > > > > set in the header type field similar to the existing KTRDROP flag. > > > > > > > > To make it easier to extend ktrace headers in the future, > > > > extend the existing header with a version field (version 0 is > > > > reserved for older records without KTR_VERSIONED) as well as > > > > new fields holding the thread ID and CPU ID. > > > It would be nice to have a way to force kernel to write v0 format. > > > > > > For instance, one of my usual work flow case is to generate ktrace.out > > > on HEAD and kdump it on stable/13. > > I can merge it into the stable/13 tomorrow as it is on my stable/13 prod > > for a long time. And inot the stable/12 +-two week. will that work for > > you? > > I think that this change is not acceptable for stable/12, due to ABI > stability guarantees. I am not sure that it is acceptable for stable/13 > as well, but there we could have a discussion about long-term viability > of the branch. > > Can you make at least the kdump changes merged (and some modified header > files merge as well), so both formats can be parsed by kdump(1)? yeah, I understand. can we rely on a ktrace p_osrel?