linux-kernel - Re: [PATCH] RTC: Add mmap method to rtc character driver

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: <20060725190357.GG4608@hmsreliant.homelinux.net>
Date:	Tue, 25 Jul 2006 15:03:57 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org, a.zummo@...ertech.it,
	jg@...edesktop.org
Subject: Re: [PATCH] RTC: Add mmap method to rtc character driver

On Tue, Jul 25, 2006 at 08:53:16PM +0200, Arjan van de Ven wrote:
> On Tue, 2006-07-25 at 14:43 -0400, Neil Horman wrote:
> > On Tue, Jul 25, 2006 at 08:32:55PM +0200, Arjan van de Ven wrote:
> > > 
> > > > > 3) this will negate the power gain you get for tickless kernels, since
> > > > > now they need to start ticking again ;( )
> > > > > 
> > > > That is true, but only in the case where someone opens up /dev/rtc, and if they
> > > > open that driver and send it a UIE or PIE ioctl, it will start ticking
> > > > regardless of this patch (or that is at least my impression).
> > > 
> > > but.. if that's X like you said.. then it's basically "always"...
> > > 
> > Well, not always (considering the number of non-X embedded systems out there),
> > but I take your point.  So it really boils down to not having a tickless kernel,
> > or an X server that calls gettimeofday 1 million times per second (I think thats
> > the number that Dave threw out there).  Unless of course, you have a third
> > alternative, which, as I mentioned before I would be happy to take a crack at,
> > if you would elaborate on your idea a little more.
> 
> well the idea that has been tossed about a few times is using a vsyscall
> function that either calls into the kernel, or directly uses the hpet
> page (which can be user mapped) to get time information that way... 
> or even would use rdtsc in a way the kernel knows is safe (eg corrected
> for the local cpu's speed and offset etc etc).
> 
Ok, that makes sense, although thats only going to be supportable on hpet
enabled systems right?  Would a "both" make more sense, so that things like X
can get user space monotonic time regardless of cpu abilities?

Regarsds
Neil

> 
> -- 
> if you want to mail me at work (you don't), use arjan (at) linux.intel.com

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *gpg keyid: 1024D / 0x92A74FA1 - http://pgp.mit.edu
 ***************************************************/
-
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/