linux-kernel - Re: 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: <21d7e9970607251304n5681bf44gc751c21fd79be99d@mail.gmail.com>
Date:	Wed, 26 Jul 2006 06:04:14 +1000
From:	"Dave Airlie" <airlied@...il.com>
To:	"Neil Horman" <nhorman@...driver.com>
Cc:	"Segher Boessenkool" <segher@...nel.crashing.org>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	a.zummo@...ertech.it, jg@...edesktop.org
Subject: Re: Re: [PATCH] RTC: Add mmap method to rtc character driver

> >
> > But userland cannot know if there is a more efficient option to
> > use than this /dev/rtc way, without using VDSO/vsyscall.
> >
> Sure, but detecting if /dev/rtc via mmap is faster than gettimeofday is an
> orthogonal issue to having the choice in the first place.  I say let the X guys
> write code to determine at run time what is more efficient to get their job
> done.  I really just wanted to give them the ability to avoid making a million
> kernel traps a second for those arches where a userspace gettimeofday is not
> yet implemented, or cannot be implemented.  It won't cost anything to add this
> feature, and if the Xorg people can write code to use gettimeofday if its faster
> than mmaped /dev/rtc (or even configured to do so at compile-time).  This patch
> doesn't create any interrupts that wouldn't be generated already anyway by any
> user using /dev/rtc, and even if X doesn't already use /dev/rtc, the added
> interrupts are in trade for an equally fewer number of kernel traps, which I
> think has to be a net savings.
>
> I'm not saying we shouldn't implement a vsyscall on more platforms to provide a
> speedup for this problem (in fact I'm interested to learn how, since I hadn't
> previously considered that as a possibility), but I think offering the choice is
> a smart thing to do until the latter solution gets propogated to other
> arches/platforms besides x86_64
>

So far the requirements are pretty much not high resolution but is
accurate and increasing. so like 10ms is fine, the current X timer is
in the 20ms range.

I think an mmap'ed page with whatever cgt(CLOCK_MONOTONIC) returns
would be very good, but it might be nice to implement some sort of new
generic /dev that X can mmap and each arch can do what they want in
it,

I'm wondering why x86 doesn't have gettimeofday vDSO (does x86 have
proper vDSO support at all apart from sysenter?),

Dave.
-
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/