Hi Davide,

quoted text
>> 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).

quoted text
> 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

quoted text
> 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.

-
unsubscribe notice
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/