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

[Neil Horman]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/