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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
