Date:	Fri, 28 Jul 2006 07:59:56 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Jim Gettys <jg@...top.org>
Cc:	Paul Mackerras <paulus@...ba.org>, Andi Kleen <ak@...e.de>,
	a.zummo@...ertech.it, jg@...edesktop.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] RTC: Add mmap method to rtc character driver

On Thu, Jul 27, 2006 at 11:29:48PM -0400, Jim Gettys wrote:
> The only awkward thing about the current interfaces is that you have to
> go from seconds and microseconds, to milliseconds, but only really when
> you represent time to X clients, which requires a bit of 64 bit of
> math...    It is true that since you have two values in the timeval
> structure, the update might require some sort of locking, which could be
> a performance lose; but there are other simple solutions to that (e.g.
> simple ring representations where you rely on the store of an index
> value to be atomic without requiring full locks and increment the index
> after updating both values, but a simple memory barrier), but those
> implementation tricks should be hidden behind an interface, and not
> exposed to application programmers..
> 
> In theory, that conversion to milliseconds only actually has to be done
> if the time is (significantly) different.
> 
> I can't forsee that this is a big deal on (most of) today's machines.
> Last I looked, the CPU runs the same speed in kernel mode as user
> mode ;-).
> 
> On the other hand, the idea of a one off Linux specific "oh, there is
> this magic file you mmap, and then you can poke at a magic location",
> strikes me as a one-off hack, and that Linux would be better off
> spending the same effort to speed up the general interface (which might
> very well do this mmap trick trick behind the scenes, as far as I'm
> concerned).
> 
> The difference is one is a standard, well known interface, which to an
> application programmer has very well defined semantics; the other, to be
> honest, is a kludge, which may expose applications to too many details
> of the hardware.  For example, exact issues of cache coherency and
> memory barriers differ between machines.
>                                 Regards,
>                                     - Jim
> 
> 
> If it's to be a kludge, it might as well be a X driver kludge (which is
> where we put it in the '80's).
> 
> 
So, setting aside for the moment any potential usefullness to X, what about the
same question in the general sense?  Is this a usefull interface to add to the
rtc driver in general, without consideration for what applications might use it?

Neil

> 
> 
> On Fri, 2006-07-28 at 09:53 +1000, Paul Mackerras wrote:
> > Andi Kleen writes:
> > 
> > > No, no, it's wrong. They should use gettimeofday and the kernel's job
> > > is to make it fast enough that they can. 
> > 
> > Not necessarily - maybe gettimeofday's seconds + microseconds
> > representation is awkward for them to use, and some other kernel
> > interface would be more efficient for them to use, while being as easy
> > or easier for the kernel to compute.  Jim, was that your point?
> > 
> > Paul.
> -- 
> Jim Gettys
> One Laptop Per Child
> 
> 
> -
> 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/

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

Powered by blists - more mailing lists