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

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