Re: [RFC][PATCH 1/4] clock_rtoffset: new syscall

From: Thomas Gleixner <tglx@linutronix.de>
To: john stultz <johnstul@us.ibm.com>
Cc: Alexander Shishkin <virtuoso@slind.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Chris Friesen <chris.friesen@genband.com>,
	Kay Sievers <kay.sievers@vrfy.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Davide Libenzi <davidel@xmailserver.org>
Subject: Re: [RFC][PATCH 1/4] clock_rtoffset: new syscall
Date: Thu, 28 Apr 2011 00:19:55 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.02.1104280015420.3323@ionos> (raw)
In-Reply-To: <1303931500.2971.14.camel@work-vm>

On Wed, 27 Apr 2011, john stultz wrote:
> On Wed, 2011-04-27 at 16:02 +0200, Thomas Gleixner wrote:
> > On Wed, 27 Apr 2011, Alexander Shishkin wrote:
> Overall looks good. I flinched a little bit at adding an internal only
> clockid but trying to avoid that would really make it messy.

Yes. It would. And we really don't want to mess with the POSIX
interfaces. Having this extension and the weird return code for
timerfd seems to be a reasonable limitation.

> > +#ifdef __KERNEL__
> > +/* This clock is not exposed to user space */
> > +#define CLOCK_REALTIME_COS		8
> > +#endif
> 
> Would something like INTERNAL_CLOCK_REALTIME_COS be more explicit?

Yes. Good point.

> > +	base = cpu_base->clock_base + HRTIMER_BASE_REALTIME_COS;
> 
> I know its the same thing, but for some reason the above makes me think
> that the clock_base could be non-zero. 
> 
> 	base = &cpu_base->clock_base[HRTIMER_BASE_REALTIME_COS];
> 
> seems more straight forward to me. But its not a huge deal.

I don't care either way :)

Thanks,

	tglx