Subject: Re: Timekeeping in NetBSD -or- getting ready to split the microsecond
To: Simon Burge <simonb@wasabisystems.com>
From: Frank Kardel <Frank.Kardel@Acrys.COM>
List: tech-kern
Date: 11/01/2005 14:46:01
Simon Burge wrote:

>Hi Frank,
>
>Frank Kardel wrote:
>
>  
>
>>Simon Burge wrote:
>>
>>    
>>
>>>      
>>>
>>Maybe we can compare the two trees and pick the better parts of both.
>>    
>>
>
>That sounds good.
>
>I've merged some of my diff with some of yours and have the following
>that still runs here.
>
>My diff is at
>ftp://ftp.NetBSD.org/pub/NetBSD/misc/simonb/timecounters-20051027.diff
>
>  
>
will pick that up tonight - feedback might take a bit.

>The key difference is that I don't really have support for both the
>old and the new ways of doing things, although I've taken some of your
>support for this.  I also haven't added any Geode support so far,
>although that will all drop in beside that diff without any problems.
>
it should. it's just a driver-like add on.

>  I
>think the Geode support should however live in arch/i386/pci/geodecntr.c
>as it's i386 specific, and we have some other existing Geode support in
>arch/i386/pci.
>  
>
you are right there - I almost had it in arch/i386 but saw the geoide.c 
which lured me
to put it into dev/pci - will move it to the arch/i386 area.

>I've still got lots of XXX comments to deal with.  How does it sound to
>iterate over this again, and then we'll form the branch based on the
>merging of our diffs?
>
>  
>
sure - no problem. I take a look at the comments mabe they point me to 
something I overlooked.

>I think at this stage we either don't want to support both timecounters
>and non-timecounters, or we want to support then within the same
>file. I don't think it will be that difficult to cut over all ports to
>timekeepers on a branch, but getting all ports physically tested might
>be a different story.
>
>  
>
I'd opt for the same file but support old and new to ease the 
transition. In my
experience getting time keeping stable again takes effort on every platform.

Keep in mind that my timecounter port also brings in the
"new" NTP API. That's where the changes in kern_ntptime_tc.c come from 
mainly.

>As to why I'd want to see timecounter support in the same file as old
>timer support, take kern/kern_clock_tc.c as an example.  I don't think
>we want both a kern_clock.c and a kern_clock_tc.c, as the former will
>disappear soon, and I don't think we want to keep the _tc suffix on
>kern_clock_tc.c after the original kern_clock.c disappears.
>
Very much agreed.

>  I also
>don't want to we want to develop on kern_clock_tc.c then rename that to
>kern_clock.c at some later stage either as we then miss any CVS history
>(or at least make it harder to use by having to refer to two different
>files).  Perhaps just having kern_clock.c say
>
>	#ifdef TIMECOUNTERS
>	   /* new code */
>	#else /* !TIMECOUNTERS */
>	   /* old code */
>	#endif
>
>is a possible compromise?
>
>  
>
sounds reasonable to me - the current non _tc.c version will have to do 
metamorphosis anyway and
this way we have all changes in one file.

>Simon.
>  
>
I'll look through your changes and take your suggestions about where to 
place the code and see what I
can make from that.

Frank