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: <20060726001042.GD5147@localhost.localdomain>
Date:	Tue, 25 Jul 2006 20:10:42 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Segher Boessenkool <segher@...nel.crashing.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	a.zummo@...ertech.it, jg@...edesktop.org
Subject: Re: [PATCH] RTC: Add mmap method to rtc character driver

On Wed, Jul 26, 2006 at 01:26:07AM +0200, Segher Boessenkool wrote:
> >>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.
> 
> No it's not.  Userland can not detect things it doesn't know
> about, and then when there is a great choice, it won't see it,
> and use the 6000kW solution (or any other really bad thing)
> instead.
> 
You're right, it won't be easy for an application to detect if gettimeofday uses
a vdso that is more lightweight than a regular syscall, but it can measure how
much cpu a periodic call to gettimeofday uses vs. how much cpu a periodic rtc
interrupt uses.  It can use that information to make an informed decision about
which interface to use.  Alternatively, a package can be built with sane
defaults in mind (always use RTC vs. always use gettimeofday).
 
> Using the old old legacy stuff when there's nothing better around
> is a fine idea; please just implement an x86 VDSO that does just
> that.  x86 is what you care about IIUC.  Don't saddle up non-x86
> systems that just happen to have a legacy RTC around, and perhaps
> x86 systems that don't sanely expose their better interfaces, with
> this quite suboptimal solution for years to come.
> 
Yes, I intend to (I've got a steep learning curve, since I've not worked much
with glibc, and I've never implemented a vdso call before), but I think thats a
great idea.  My point is, why not have both interfaces available?  That way,
implementations which can't do any better via a vdso call can still get a
speedup through the legacy interface.

Neil

> 
> Segher
-
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/