>> > If that is the case, should we change the note to say since which glibc (do we >> > care about any other libc?) and kernel version these are safe on SMP and keep >> > the note for people using olders version ? >> >> Exactly. See below. >> >> > Also, I didn't check if kernel support was backported to Linux 2.4... >> >> 2.4.x doesn't have the two CPUTIME clocks. > > Thanks, I didn't know that :-) > >> >> How does the patch below look to you? > > Looks good, thanks! But I it failed to apply here as it is. And a minor question > below >> --- a/man2/clock_getres.2 >> +++ b/man2/clock_getres.2 >> @@ -221,12 +221,13 @@ are available. >> (See also >> .BR sysconf (3).) >> .SH NOTES >> -.SS Note for SMP systems >> -The >> +.SS Historical note for SMP systems >> +Before Linux added kernel support for >> .B CLOCK_PROCESS_CPUTIME_ID >> and >> -.B CLOCK_THREAD_CPUTIME_ID >> -clocks are realized on many platforms using timers from the CPUs >> +.BR CLOCK_THREAD_CPUTIME_ID , >> +glibc implemented these clocks on many platforms using timer >> +registers from the CPUs >> (TSC on i386, AR.ITC on Itanium). >> These registers may differ between CPUs and as a consequence >> these clocks may return >> @@ -252,6 +253,15 @@ Glibc contains no provisions to deal with these >> offsets (unlike the Linux >> Kernel). >> Typically these offsets are small and therefore the effects may be >> negligible in most cases. >> + >> +Since glibc 2.4, > > Is the new line here on purpose ? It makes no difference to the output; I often break long source lines at punctuation points. Thanks for all your help getting to the final result, Rodrigo. Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
