are you sure this is a good idea? this adds an implicit gettimeofday
(thought no entry/exit kernel) to every getevents syscall with a
"when" specificed, so the user may now need to do gettimeofday both
externally and internally to use the previous "timeout" feature (given
the kernel can delay only of a timeout, so the kernel has to calculate
the timeout internally now). I guess I prefer the previous version that
had the "timeout" information instead of "when". Also many soft
multimedia only expect the timeout to take "timeout", and if a frame
skips they'll just slowdown the frame rate, so they won't be real time
but you'll see something on the screen/audio. Otherwise they can keep
timing out endlessy if they cannot keep up with the stream, and they
will show nothing rather than showing a low frame rate.
So I'm not very excited about this change, I would prefer the previous
version. Also consider with the vsyscall doing the gettimeofday
calculation in userspace based on "when" rather than in-kernel isn't
going to be more expensive than your new API even of applications that
really want the "when" behaviour instead of the "timeout". While the
applications that wants the "timeout" this way we'll be forced to a
vgettimeofday in userspace and one in kernel which is a pure overhead
for them.
So unless anybody can see a flaw in my reasoning, I would suggest you to
backout the "when" change and to resend to Linus.
Also the vsyscall sections would better be deleted instead of under #if
0.
Everything else looks great, thanks!
Andrea
-
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/