Re: git: fc90f3a28145 - main - ktrace: Increase precision of timestamps.
- In reply to: Konstantin Belousov : "Re: git: fc90f3a28145 - main - ktrace: Increase precision of timestamps."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 19 Jul 2022 17:50:24 UTC
On Mon, Jul 18, 2022 at 03:09:29PM +0300, Konstantin Belousov wrote: > On Mon, Jul 18, 2022 at 02:11:40PM +0300, Dmitry Chagin wrote: > > 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? > > I am not sure I follow. How a process p_osrel is relevant there? I mean something like this: https://reviews.freebsd.org/D35851 > > What I said is that you could, for instance, only merge _kdump_ changes, > to teach it how to interpret both old and new formats, while leaving > stable/13 kernel to generate old format.