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

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?

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.