Re: git: fc90f3a28145 - main - ktrace: Increase precision of timestamps.

From: Dmitry Chagin <dchagin_at_heemeyer.club>
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.