On Fri, Nov 14, 2008 at 04:08, Michael Kerrisk <mtk.manpages@xxxxxxxxxxxxxx> wrote: > Hi Bert, > > Thanks for looking this over. > > On Thu, Nov 13, 2008 at 1:45 PM, Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> wrote: >> Hi Michael, >> >> On Thu, Nov 13, 2008 at 15:06, Michael Kerrisk >> <mtk.manpages@xxxxxxxxxxxxxx> wrote: >>> Hi Bert, >>> >>> I created this page by removing the CPU_*() material from >>> sched_setscheduler.2 and adding documentation of the many other macros >>> that have been added in more recent glibc releases. >>> >>> I remember looking at a mail thread you pointed at a few days back >>> where you said the interface of the CPU_*S() macros is somewhat >>> confusing in its use of bits in some places, and bytes in others. >>> It's hard to disagree with you -- so I included an example in the >>> man-pages which hopefully might reduce the confusion. >>> >>> Of course, since these are macros, my use of types in the prototypes >>> in the SYNOPSIS is in many cases invention; let me know if something >>> looks weird. >>> >>> Also, take a look at >>> http://sourceware.org/bugzilla/show_bug.cgi?id=7029. Unless I'm >>> confused (which is always possible), this is a real bug. Do you >>> agree? >> "It's hard to disagree with you." I can confirm this here on my x86-64 >> box, a x86-32 exec returns 2048 the x86-64 1024. > > Yep. In fact UD has already fixed it today. > > [...] > >>> .BI "int CPU_EQUAL_S(size_t " setsize ", cpu_set_t *" set1 \ >>> ", cpu_set_t *" set2 ); >> Even I like to see the equivalent C prototypes, I think this should be >> noted earlier that these are actually macros. > > Well, I do mention that they are macros a number of times. What more > do you think I should add? Hmm, I thought something like "hey these are only theoretical C prototypes" > >> Also, I would like to see a note that the cpu_set_t type is opaque (as >> from the glibc manual) > > I added something on that. > >> but there is no official copy operator. The >> glibc developer suggest using memcpy for this (see the reminder of >> this thread I posted). > > Yes, good point. I Added a NOTES section mentioning memcpy(3). > >> And you should not use '=' because of the >> dynamically allocated ones. >> >> Last but not least, because CPU_ALLOC{,_SIZE} rounds the num_cpus >> argument up (i.e. CPU_ALLOC_SIZE(1) == sizeof(unsigned long)) there >> are probably more cpus possible in this set than you requested, so >> these blind bits should be mentioned as undefined. > > I added something in NOTES about this. > >> Now to the naming confusion, I think the main problem is CPU_SETSIZE >> and the setsize arguement to the CPU_*_S macros. The former is in bits >> the latter in bytes. Either put a note to CPU_SETSIZE that this is in >> bits and you should not pass this as an setsize argument to any >> CPU_*_S macro, because of the similar name. Or, rename the setsize >> argument to something other, and use the setsize name for the >> CPU_ALLOC{,_SIZE}, too. >> >> I think option one should suffice. > > Again, I added something to NOTES on this. > > [...] > >>> This macro provides the value that can be used for >> the >>> .I setsize >> argument > > Done. > > Thanks Bert. New version looks good. Thank You. Bert > > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git > man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html > Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html > -- 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
