From 12c341b917921eb631026ec44a284c4d884e5de6 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 6 Mar 2013 21:52:20 +0100 Subject: IRC. --- open_issues/clock_gettime.mdwn | 121 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 118 insertions(+), 3 deletions(-) (limited to 'open_issues/clock_gettime.mdwn') diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index 5345ed6b..83ad81e8 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -23,7 +23,8 @@ applications assume that it is. What about adding a nanosecond-precision clock, too? --[[tschwinge]] -IRC, freenode, #hurd, 2011-08-26: + +# IRC, freenode, #hurd, 2011-08-26 < pinotree> youpi: thing is: apparently i found a simple way to have a monotonic clock as mmap-able device inside gnumach @@ -40,7 +41,8 @@ IRC, freenode, #hurd, 2011-08-26: < braunr> sure < youpi> and that's the way I was considering implementing it -IRC, freenode, #hurd, 2011-09-06: + +# IRC, freenode, #hurd, 2011-09-06 yeah, i had a draft of improved idea for also handling nanoseconds @@ -69,3 +71,116 @@ IRC, freenode, #hurd, 2011-09-06: yes And it will forever be a witness of the evolving of this map_time interface. :-) + + +# IRC, freenode, #hurd, 2013-02-11 + +In context of [[select]]. + + braunr: would you send for review (and inclusion) your + time_data_t addition? + this way we could add nanosecs-based utime rpc (and then their + implementation in libc) + pinotree: it's part of the hurd branch + do you want it sent separately ? + yeah + ok + let me get it right first :) + sure :) + + +## IRC, freenode, #hurd, 2013-02-12 + + pinotree: + http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a + uh nice + will need two small inline functions to convert time_data_t <-> + timespec, but that's it + hm right + i could have thought about it + but i'll leave it for another patch :p + oh sure, no hurry + + +## IRC, freenode, #hurd, 2013-02-19 + + braunr: about time_data_t, I get it's needed that it be an array + so it can be passed by reference, not by value? + by address, yes + that's the difference between array and struct + + +## IRC, freenode, #hurd, 2013-02-25 + + braunr: why did you want to see time_data passed as pointer, not as + struct? + to microoptimize + the struct is 2 64-bit integers + well, we already pass structs along in a few cases, + e.g. io_statbuf_t, rusage_t, etc. + be it written t[0].sec or t->sec, it seems odd + copying 2 64bit integers is not much compared to the potential for + bugs here + bugs ? + yes, as in trying to access t[1], passing a wrong pointer, etc. + or the reader frowning on "why is this case different than the + others?" + well, i'm already usually frowning when i see what mig does .. + right + on the plus side, it's only the client side, i.e. mostly glibc, + which sees the t[0] + and the practice established by my patch is to convert to struct + timespec as soon as possible + the direct use of this type is therefore limited + could we define time_data_t as a struct time_data * instead of + struct time_data[1] ? + (in the.h) + that would make more sense to define a struct time_data, and pass a + pointer to it + i'm not sure + the mach server writing guide was very clear about array implying + a C array too + and i remember having compilation problems before doing that + but i don't remember their nature exactly + I'm not sure to understand what you said about converting to struct + timespec + what makes it not possible now? + and what is the relation with being an array or a pointer? + concerning struct timespec, what i mean is that the functions + called by the mig stub code directly convert time_data_t to a struct + timespec (which is the real type used throughout the hurd code) + about the rest, i'm not sure, i'd have to try again + mig just assumes it's an array + and why not just using struct timespec? + (for the mig type too) + my brain can't correctly compute variable sized types in mig + definition files + i wanted something that would remain correct for the 64-bit port + ah, you mean because tv_nsec is a long, which will not be the same + type? + and tv_sec being a time_t (thus a long too) + but we have the same issue e.g. for the rusage structure, don't we? + yes + so we'll have to fix things for that too anyway + sure + making a special case will not necessarily help + but it doesn't mean new interfaces have to be buggy too + well, using the proper type in the server itself is nicer + instead of having to convert + yes + i'm not exactly sure where to declare struct timespec then + should it be declared in hurd_types.h, and simply reused by the + libc headers ? + ? AIUI, it's the converse, hurd_types.h uses the struct timespec + from libc headers, and defines timespec_t + ok + timespec_t being the internal type whose definition gets done right + for mig to do the right thing + yes + i see + so, you'd like a struct of integer_t instead of an array of + signed64 + for our current 32bit userland yes + do you want to make the changes yourself or should i add a new + branch ? + and we'll make that a 64bit struct when we have a64bit userland -- cgit v1.2.3