Date: Wed, 1 May 1996 12:55:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bde@freefall.freebsd.org, current@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/include clock.h src/sys/i386/isa clock.c src/sys/i386/i386 machdep.c Message-ID: <199605011955.MAA10137@phaeton.artisoft.com> In-Reply-To: <199605010917.TAA18171@godzilla.zeta.org.au> from "Bruce Evans" at May 1, 96 07:17:58 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> This change is supposed to make timekeeping more accurate when no > external clocks are available. The RTC is probably more accurate > than the i8254 clock so it is used as a reference. The nominal > frequencies can be overridden using sysctl if desired. [ ... timer code changes ... ] I'd like to see a more chip/service-centric breakdown of functional support within the kernel. Specifically, the use of Intel ISA bridge chipsets is common in PReP and Apple and DEC Hardware. Because of this, common timer functions for DEC Alpha machines and PPC machines are implemented with the same, or emulations of, chips which are in Intel boxes. For instance, the packaging of the timer1/timer2 services is Intel architecture specific because of the use of Intel assembly constructs and the use of the assumption that, for the internal speaker, these will be the output drivers. If this were broken along "chip provides these 5 functions..." or similar lines on a per chip basis, this would vastly increase code reusability. It would also mean that time changes on one architecture don't kill another. For instance, I'd like to see the code not depend on i586 detection for processor cycle clocks... I'd rather see the i586 cycle clock tagged as a low cost, fixed frequency, calibratable device not to be used for calibration. And so on. A given gridge chip might export timer1, timer2, and internal speaker interfaces as a single functional unit (ie: in the PC, the driver is latched this way for the speaker). Speaker services may be seperate, or not provided at all by a similar "black box" in another machine, which uses the same chip, but does nmot provide the hardware speaker latching gate interface for driving an internal "beep" speaker. Just something to be thinking about... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605011955.MAA10137>