lkml.org 
[lkml]   [2004]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC][PATCH] new timeofday i386 hooks (v.A0)
    On 2 Sep 2004 at 18:44, George Anzinger wrote:

    > john stultz wrote:
    > > All,
    > > This patch implements the minimal i386 architecture hooks to enable the
    > > new time of day subsystem code. It applies on top of my
    > > linux-2.6.9-rc1_timeofday-core_A0 patch and with this patch applied, you
    > > can test the new time of day subsystem on i386. Basically it adds the
    > > call to timeofday_interrupt_hook() and cuts alot of code out of the
    > > build. The only new code is the sync_persistant_clock() function which
    > > is mostly ripped out of do_timer_interrupt(). Pretty un-interesting.
    > >
    > > I look forward to your comments and feedback.
    > >
    > > thanks
    > > -john
    > >
    > > linux-2.6.9-rc1_timeofday-i386_A0.patch
    > > =======================================
    > > diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
    > > --- a/arch/i386/Kconfig 2004-09-02 13:29:59 -07:00
    > > +++ b/arch/i386/Kconfig 2004-09-02 13:29:59 -07:00
    > > @@ -14,6 +14,10 @@
    > > 486, 586, Pentiums, and various instruction-set-compatible chips by
    > > AMD, Cyrix, and others.
    > >
    > > +config NEWTOD
    > > + bool
    > > + default y
    > > +
    > > config MMU
    > > bool
    > > default y
    > > diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
    > > --- a/arch/i386/kernel/time.c 2004-09-02 13:29:59 -07:00
    > > +++ b/arch/i386/kernel/time.c 2004-09-02 13:29:59 -07:00
    > > @@ -67,6 +67,8 @@
    > >
    > > #include "io_ports.h"
    > >
    > > +#include <linux/timeofday.h>
    > > +
    > > extern spinlock_t i8259A_lock;
    > > int pit_latch_buggy; /* extern */
    > >
    > > @@ -87,6 +89,7 @@
    > >
    > > struct timer_opts *cur_timer = &timer_none;
    > >
    > > +#ifndef CONFIG_NEWTOD
    > > /*
    > > * This version of gettimeofday has microsecond resolution
    > > * and better than microsecond precision on fast x86 machines with TSC.
    > > @@ -169,6 +172,7 @@
    > > }
    > >
    > > EXPORT_SYMBOL(do_settimeofday);
    > > +#endif
    > >
    > > static int set_rtc_mmss(unsigned long nowtime)
    > > {
    > > @@ -194,12 +198,39 @@
    > > * Note: This function is required to return accurate
    > > * time even in the absence of multiple timer ticks.
    > > */
    > > +#ifndef CONFIG_NEWTOD
    > > unsigned long long monotonic_clock(void)
    > > {
    > > return cur_timer->monotonic_clock();
    > > }
    > > EXPORT_SYMBOL(monotonic_clock);
    > > +#endif
    > >
    > > +void sync_persistant_clock(struct timespec ts)
    > > +{
    > > + /*
    > > + * If we have an externally synchronized Linux clock, then update
    > > + * CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
    > > + * called as close as possible to 500 ms before the new second starts.
    > > + */
    > > + if (ts.tv_sec > last_rtc_update + 660 &&
    > > + (ts.tv_nsec / 1000)
    > > + >= USEC_AFTER - ((unsigned) TICK_SIZE) / 2 &&
    > > + (ts.tv_nsec / 1000)
    > > + <= USEC_BEFORE + ((unsigned) TICK_SIZE) / 2) {
    > > + /* horrible...FIXME */
    > > + if (efi_enabled) {
    > > + if (efi_set_rtc_mmss(ts.tv_sec) == 0)
    > > + last_rtc_update = ts.tv_sec;
    > > + else
    > > + last_rtc_update = ts.tv_sec - 600;
    > > + } else if (set_rtc_mmss(ts.tv_sec) == 0)
    > > + last_rtc_update = ts.tv_sec;
    > > + else
    > > + last_rtc_update = ts.tv_sec - 600; /* do it again in 60 s */
    > > + }
    > > +
    > I have wondered, and continue to do so, why this is not a timer driven function.

    I think it depends on how reliable timers are regarding in-time triggering. This
    code has to be executed on-time to make sense. Really.

    > It just seems silly to check this every interrupt when we have low overhead
    > timers for just this sort of thing.
    >
    > I wonder about the load calc in the same way...

    That's completely different.

    ...

    Regards,
    Ulrich


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.034 / U:2.016 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site