Messages in this thread | | | Subject | Re: [PATCH] RTC: Add mmap method to rtc character driver | From | Jim Gettys <> | Date | Thu, 27 Jul 2006 23:29:48 -0400 |
| |
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).
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |