Re: [RFC][PATCH] new timeofday arch specific hooks (v. A3)

From: john stultz (johnstul_at_us.ibm.com)
Date: 03/14/05

  • Next message: Wiktor: "Building server-farm" 
    To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:	Mon, 14 Mar 2005 10:09:14 -0800

    On Sat, 2005-03-12 at 16:52 +1100, Benjamin Herrenschmidt wrote:
    > On Fri, 2005-03-11 at 17:25 -0800, john stultz wrote:
    > > All,
    > > This patch implements the minimal architecture specific hooks to enable
    > > the new time of day subsystem code for i386, x86-64, ia64, ppc32 and
    > > ppc64. It applies on top of my linux-2.6.11_timeofday-core_A3 patch and
    > > with this patch applied, you can test the new time of day subsystem.
    > >
    > > Basically it configs in the NEWTOD code and cuts alot of code out of the
    > > build via #ifdefs. I know, I know, #ifdefs' are ugly and bad, and the
    > > final patch will just remove the old code. For now this allows us to be
    > > flexible and easily switch between the two implementations with a single
    > > define.
    > >
    > > New in this version:
    > > o ppc32 arch code (by Darrick Wong. Many thanks to him for this code!)
    > > o ia64 arch code (by Max Asbock. Many thanks to him for this code!)
    > > o minor cleanups moving code between the arch and timesource patches
    > >
    > > Items still on the TODO list:
    > > o s390 arch port (hey Martin: nudge, nudge :)
    > > o arch specific vsyscall/fsyscall interface
    > > o other arch ports (volunteers wanted!)
    >
    > I'm not what the impact will be with the vDSO implementation of
    > gettimeofday which relies on the bits in systemcfg (tb_to_xs etc...).

    Oh yea, the vDSO stuff slipped in after I last tested the ppc64 bits, so
    I wouldn't be surprised if that's broken. For now I'm just disabling the
    vsyscall/fsyscall/vDSO bits on the arches that support it until I get a
    generic interface setup that would allow it to be consistent with the
    new time infrastructure. Hopefully I'll have that done (I'm targeting
    x86-64 atleast) by the next release.

    thanks
    -john

    -
    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/

  • Next message: Wiktor: "Building server-farm"

    Relevant Pages

    • Re: Linux does not care for data integrity (was: Disk write cache)
      ... Subsystem maintainers will usually know the shape their code is in and ... parallel ATA interfaces, so how do I start a list without information? ... AIC7XXX was once reported to have it, experimentally, I don't know what ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Too much error in __const_udelay() ?
      ... >> pointed to the fact that certain important udelays in the USB ... >> subsystem aren't actually waiting long enough. ... your test output is a bit confusing (changes to __const_udealy ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] Small PCI core patch
      ... On 11/21/05, Benjamin Herrenschmidt wrote: ... They really doesn't give a shit ... catch is the part about advancing the Linux desktop, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.4.23aa1 - scsi/pcmcia qlogic still does not build (m)
      ... I disabled the subsystem in order to complete the build. ... aha152x.o: multiple definition of `cleanup_module' ... ld: Warning: size of symbol `cleanup_module' changed from 40 to 16 in ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: momentary sensors failure in gkrellm2
      ... kernel), hints about where the problem lies would help. ... there any relevant error messages in the logs? ... (although they share the same subsystem) ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)