mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Thomas Gleixner <tglx@tglx.de>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Miroslav Lichvar <mlichvar@redhat.com>,
	hmurray@megapathdsl.net, Ulrich Drepper <drepper@redhat.com>,
	Michael Tatarinov <kukabu@gmail.com>
Subject: [PATCH] You say MOD_NANO, I say ADJ_NANO
Date: Thu, 27 Aug 2009 17:04:42 -0700	[thread overview]
Message-ID: <1251417882.7905.42.camel@localhost.localdomain> (raw)

MOD_NANO, ADJ_NANO, MOD_NANO, ADJ_NANO!
Lets call the whole thing off!
But oh! If we call the whole thing off,
Then we must part.
And oh! If we ever part,
Then that might break my heart^H^H^H^Hclock!
So, if you like MOD_NANO and I like ADJ_NANO,
I'll include MOD_NANO and give up ADJ_NANO (not really!).
For we know we need each other,
So we better call the calling off off.
Let's call the whole thing off!


The tumultuous NTP and Linux relationship has hit another snag: Ends up
NTPd still uses the "xntp 3.4 compatability names" and when the STA_NANO
value was added (along with ADJ_NANO), NTPd expected MOD_NANO to be
added and has apparently hit some build errors.

Report to ntp hackers:
https://lists.ntp.org/pipermail/hackers/2009-August/004455.html

Related Bugs:
https://support.ntp.org/bugs/show_bug.cgi?id=1219
https://bugzilla.redhat.com/show_bug.cgi?id=505566

So in an effort to make peace, here's a patch to help get things
building again. I also have updated the comment to make sure folks don't
think the MOD_* values are just legacy constants.

Of course, NTPd really uses the glibc-headers, so those will need to be
similarly updated before things are working again (the RH bug above
should probably cover that).

Thanks to Michael Tatarinov and Hal Murray for finding and reporting the
issue!

thanks
-john

Signed-off-by: John Stultz <johnstul@us.ibm.com>

diff --git a/include/linux/timex.h b/include/linux/timex.h
index e6967d1..782ccd4 100644
--- a/include/linux/timex.h
+++ b/include/linux/timex.h
@@ -115,13 +115,16 @@ struct timex {
 #define ADJ_OFFSET_SS_READ	0xa001	/* read-only adjtime */
 #endif
 
-/* xntp 3.4 compatibility names */
+/* NTP userland likes the MOD_ prefix better */
 #define MOD_OFFSET	ADJ_OFFSET
 #define MOD_FREQUENCY	ADJ_FREQUENCY
 #define MOD_MAXERROR	ADJ_MAXERROR
 #define MOD_ESTERROR	ADJ_ESTERROR
 #define MOD_STATUS	ADJ_STATUS
 #define MOD_TIMECONST	ADJ_TIMECONST
+#define MOD_TAI	ADJ_TAI
+#define MOD_MICRO	ADJ_MICRO
+#define MOD_NANO	ADJ_NANO
 
 
 /*




             reply	other threads:[~2009-08-28  0:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-28  0:04 john stultz [this message]
2009-08-28 12:57 ` [tip:timers/ntp] ntp: Provide compability defines (You say MOD_NANO, I say ADJ_NANO) tip-bot for john stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1251417882.7905.42.camel@localhost.localdomain \
    --to=johnstul@us.ibm.com \
    --cc=drepper@redhat.com \
    --cc=hmurray@megapathdsl.net \
    --cc=kukabu@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlichvar@redhat.com \
    --cc=tglx@tglx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome