Re: CVS commit: src/sys

2017-01-04 Thread Paul Goyette
On Wed, 4 Jan 2017, Christos Zoulas wrote: On Jan 5, 9:28am, p...@whooppee.com (Paul Goyette) wrote: -- Subject: Re: CVS commit: src/sys | On Thu, 5 Jan 2017, Paul Goyette wrote: | | > It seems that pretty much everyone is in favor of using bintime() for the | > "raw" timestamp data in

Re: CVS commit: src/sys

2017-01-04 Thread Paul Goyette
On Thu, 5 Jan 2017, Paul Goyette wrote: It seems that pretty much everyone is in favor of using bintime() for the "raw" timestamp data in kernhist. I'll go ahead and start working on the required changes. One last question: Does this require a kernel version bump? I didn't bump

Re: CVS commit: src/sys

2017-01-04 Thread Christos Zoulas
On Jan 5, 9:28am, p...@whooppee.com (Paul Goyette) wrote: -- Subject: Re: CVS commit: src/sys | On Thu, 5 Jan 2017, Paul Goyette wrote: | | > It seems that pretty much everyone is in favor of using bintime() for the | > "raw" timestamp data in kernhist. I'll go ahead and start working on the

Re: CVS commit: src/sys

2017-01-04 Thread Paul Goyette
On Wed, 4 Jan 2017, Frank Kardel wrote: Completely agreed, That's why I proposed to consider struct bintime. We can tackle various aspects of improving the implementations benefiting from the improved APIs at any time later. IMHO struct bintime is sufficiently powerful enough to cover the

Re: CVS commit: src/sys

2017-01-04 Thread Frank Kardel
On 01/04/17 09:37, Paul Goyette wrote: On Wed, 4 Jan 2017, Frank Kardel wrote: I would also suggest a 64 bit fraction like in struct bintime, which we already have and use internally for timekeeping anyway along with the timespec, timeval conversion functions. Thus collecting can be faster as

Re: CVS commit: src/sys

2017-01-04 Thread Frank Kardel
I would also suggest a 64 bit fraction like in struct bintime, which we already have and use internally for timekeeping anyway along with the timespec, timeval conversion functions. Thus collecting can be faster as we don't need to make the conversions when collectiing. I deem converting at

Re: CVS commit: src/sys

2017-01-04 Thread Paul Goyette
On Wed, 4 Jan 2017, Frank Kardel wrote: On 01/04/17 09:37, Paul Goyette wrote: On Wed, 4 Jan 2017, Frank Kardel wrote: I would also suggest a 64 bit fraction like in struct bintime, which we already have and use internally for timekeeping anyway along with the timespec, timeval conversion

Re: CVS commit: src/sys

2017-01-04 Thread Frank Kardel
I agree, the decision is whether we want bintime in the export format. For the microtime/nanotime question (see kern/kern_tc.c): binuptime()=scaled time counter read bintime()=binuptime()+bootimeoffset nanotime()=bintime()+bintime2timespec()

re: CVS commit: src/sys

2017-01-04 Thread matthew green
> The get-versions are cheaper, but they only provide a cached timestamp > from basically the last hardclock() event. So they are not really > suitable for > high resolution time stamping - but probably ok for file system time > stamps and probably device drivers. for fwiw, i think we may want

Re: CVS commit: src/sys

2017-01-04 Thread Taylor R Campbell
Date: Wed, 04 Jan 2017 14:51:01 +0700 From: Robert Elz Date:Wed, 04 Jan 2017 14:23:12 +0700 From:Robert Elz Message-ID: <3987.1483514...@andromeda.noi.kre.to> Ignore this gibberish.. | division into a

Re: CVS commit: src/sys

2017-01-04 Thread Frank Kardel
There are two things - the extended resolution and general timing handling. The extendend resolution would be done providing the API. But there is quite some work to make the APIs fullfull the expectations. For that we would need to go into the tickless direction and use precicion (one-) time

Re: CVS commit: src/sys

2017-01-04 Thread Taylor R Campbell
Date: Wed, 04 Jan 2017 10:58:47 +0100 From: Frank Kardel I agree, the decision is whether we want bintime in the export format. Sounds good to me. We should use bintime more often. I have been meaning to add some high-resolution timer-related APIs that use it,

re: CVS commit: src/sys/ddb

2017-01-04 Thread matthew green
> Modified Files: > src/sys/ddb: db_interface.h > > Log Message: > add a simple stacktrace macro thanks! this is always annoying to do. .mrg.

Re: CVS commit: src/sys

2017-01-04 Thread Robert Elz
Date:Wed, 04 Jan 2017 22:06:35 +0100 From:Frank Kardel Message-ID: <586d63db.9060...@netbsd.org> | The extendend resolution would be done providing the API. IMO, what is important right now, is that when designing new APIs (which is what Paul is

Re: CVS commit: src/sys

2017-01-04 Thread Frank Kardel
Completely agreed, That's why I proposed to consider struct bintime. We can tackle various aspects of improving the implementations benefiting from the improved APIs at any time later. IMHO struct bintime is sufficiently powerful enough to cover the interface stability requirements (nsec are