Bryan Cantrill wrote: > On Tue, Aug 04, 2009 at 09:45:44PM +0000, Mike Shapiro wrote: >> >>> Hi Mike >>> >>> Thanks for looking at the webrev. Two quick questions before I push the >>> latest version: >>> >>> (1) wrt to gethrtime() during kmdb, I understand that mdb implements >>> it's own gethrtime(). But I'm not sure what to do within mdb_get_lbolt >>> in that situation. Should I just #ifdef _KMDB it out ? >>> >>> (2) since this project is removing the lbolt variables, We've received >>> requests for a ::time dcmd that would return lbolt, lbolt64 or >>> gethrtime. What's your opinion on adding this new dcmd ? >>> >>> Thanks, >>> Rafael >> I don't understand-- what project is removing the lbolt variables? >> Your webrev is just about adding an mdb API. Also my point >> about kmdb's gethrtime() is that it just increments an integer >> and therefore you cannot backward compute an lbolt value from that. >> >> Can we start from the top: what problem are we trying to solve here? > > Yes, do tell. drv_getparm(LBOLT) must continue to work, and presumably > there is a datum to store the variable that drv_getparm(9F) describes: > > LBOLT Read the value of lbolt. lbolt is a clock_t that > is unconditionally incremented by one at each > clock tick. No special treatment is applied when > this value overflows the maximum value of the > signed integral type clock_t. When this occurs, > its value will be negative, and its magnitude will > be decreasing until it again passes zero. It can > therefore not be relied upon to provide an indica- > tion of the amount of time that passes since the > last system reboot, nor should it be used to mark > an absolute time in the system. Only the differ- > ence between two measurements of lbolt is signifi- > cant. It is used in this way inside the system > kernel for timing purposes.
Yes, drv_getparm(LBOLT), ddi_get_lbolt(9F) and ddi_get_lbolt64(9F), the latter being added now, will all continue to work. > So what exactly do you mean by "removing the lbolt variables"? The tickless kernel project is reimplementing the services provided by the clock cyclic in an event driven way. For this sub-project we're decoupling the lbolt variables from clock and providing the exact same service through routines that will derive the lbolt value from gethrtime()/nsec_per_tick. We're migrating all references of lbolt and lbolt64 to ddi_get_lbolt(9F) and ddi_get_lbolt64(9F), and making sure no functionality is affected by this change. Our project page (http://www.opensolaris.org/os/project/tickless) has more information on each of the sub-projects, as well as our current test plan for the lbolt transition. Thanks, Rafael
