linux-kernel - Re: [PATCH] Posix CLOCK_RTC interface proof of concept

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] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1009181127090.2416@localhost6.localdomain6>
Date:	Sat, 18 Sep 2010 11:31:53 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Richard Cochran <richardcochran@...il.com>
cc:	john stultz <johnstul@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	David Brownell <david-b@...bell.net>
Subject: Re: [PATCH] Posix CLOCK_RTC interface proof of concept

On Sat, 18 Sep 2010, Richard Cochran wrote:

> On Fri, Sep 17, 2010 at 11:42:38AM -0700, john stultz wrote:
> > On Fri, 2010-09-17 at 12:59 +0200, Thomas Gleixner wrote:
> > > That's basically a copy of enqueue_hrtimer(). Can't we use
> > > k_itimer.it.real for this and reuse the related functions in
> > > hrtimer.c? Not sure if it's worth the trouble though.
> > 
> > Yes, there's also a similar duplication in drivers/char/mmtimer.c and
> > Richard Cochran commented on the same (although I'm not sure if he ended
> > up using the hrtimer for his similar PTP code).
> 
> After taking a look at the hrtimer code, I decided to remove the timer
> implementation from the patch set. I do have the userland interface to
> timer_create/settime in place, but no clock drivers implement it yet.
>  
> > I was hoping to find something I could re-use in the hrtimer code, but
> > it seemed a little tightly linked to the fixed CLOCK_MONOTONIC/REALTIME
> > bases.
> 
> That was my impression, too. It looks like hrtimers are hard-coded to
> the clock event device via a global per-cpu variable. Would it be
> possible to decouple this for multiple, different clock event devices?

It needs some thought because the REALTIME/MONOTONIC implementation
needs to stay with the per cpu ness, but for RTC and others we need a
global queue. Though it shouldn't be too hard to solve that.

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/