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

[Neil Horman <nhorman@tuxdriver.com>]

On Tue, Jul 25, 2006 at 03:33:18PM -0700, H. Peter Anvin wrote:
> Neil Horman wrote:
> >>
> >Yes, but if its in trade for something thats being used currently which 
> >hurts
> >more (case in point being the X server), using this solution is a net gain.
> >
> >I'm not arguing with you that adding a low res gettimeofday vsyscall is a 
> >better
> >long term solution, but doing that requires potentially several 
> >implementations
> >in the C library accross a range of architectures, some of which may not 
> >be able
> >to provide a time solution any better than what the gettimeofday syscall
> >provides today.  The /dev/rtc solution is easy, available right now, and 
> >applies
> >to all arches.  It has zero impact for systems which do not use it, and for
> >those applications which make a decision to use it instead of an alternate
> >method, the result I expect will be a net gain, until such time as we code 
> >up,
> >test and roll out a vsyscall solution 
> >
> 
> Quick hacks are frowned upon in the Linux universe.  The kernel-user 
> space interface is supposed to be stable, and thus a hack like this has 
> to be maintained indefinitely.
> 
> Putting temporary hacks like this in is not a good idea.
> 
Only if you make the mental leap that this is a hack; its not.  Its a new
feature for a driver.  mmap on device drivers is a well known and understood
interface.  There is nothing hackish about it.  And there is no need for it to
be temporary either.  Why shouldn't the rtc driver be able to export a monotonic
counter via the mmap interface? mmtimer does it already, as do many other
drivers.  Theres nothing unstable about this interface, and it need not be short
lived.  It can live in perpituity, and applications can choose to use it, or
migrate away from it should something else more efficient become available (a
gettimeofday vsyscall).  More importantly, it can continue to be used in those
situations where a vsyscall is not feasable, or simply maps to the nominal slow
path kernel trap that one would find to heavy-weight to use in comparison to an
mmaped page.

Neil
  
> 	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/