Hi Davide, >> This function is *not at all* equivalent to the "get" >> functionality of the previous APIs. The "get" functionality >> of POSIX timers (for example) returns a structure that contains >> the timer interval and the *time until the next expiration of >> the timer* (not the initial timer string, as your code above >> does). >> So come up with a reliable, race-free way of doing that in >> userspace. Then make it work for both CLOCK_MONOTONIC and >> CLOCK_REALTIME timers. (You'll certainly need to be making >> some additional system calls, by the way: at least some >> calls to clock_gettime().) > > No, I don't think I will. Since 1) it's so trivial it's not even > challenging
Well, it seems to me that the proposed library wrapper code could start to get rather verbose by the time one adds in these changes (plus the mutexes). > 2) you know it can be done (I assume) Sorry -- I was probably speaking too rhetorically. In fact, it's not completely clear to me that it can (always) be done. For example, the answer depends on knowing the clockid. But what if the file descriptor has been handed off to some code that doesn't know the clock type (i.e., isn't accessing the fd via your suggested library)? Cheers, Michael > 3) it solves a non-case > made up to justify an API/kernel-code bloating. > But you don't need *my* signoff. Cook a working patch, make a case for it, > and gather support and signoffs. I won't be acking it because, as I said > many times, I think it's useless bloating. - 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/