linux-kernel - Re: [RFC][PATCH 1/4] clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1104280015420.3323@ionos>
Date:	Thu, 28 Apr 2011 00:19:55 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	john stultz <johnstul@...ibm.com>
cc:	Alexander Shishkin <virtuoso@...nd.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Friesen <chris.friesen@...band.com>,
	Kay Sievers <kay.sievers@...y.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Davide Libenzi <davidel@...ilserver.org>
Subject: Re: [RFC][PATCH 1/4] clock_rtoffset: new syscall

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