Re: [hwloc-devel] last API possible changes
Brice Goglin wrote: > Hello, > > A couple other things that I am not sure about in the API: > Everything is done, so I am ok with releasing something now (once the dynamic cpusets will be discussed). We talked about adding the physical distances into the XML output of lstopo, but it requires some non-trivial changes (and some thinking), so I'd rather not put it in 0.9.1. XML backward compatibility shouldn't be too bad anyway (maybe a warning if an unknown/expected node is found, that's it). Brice
Re: [hwloc-devel] last API possible changes
Samuel Thibault, le Mon 21 Sep 2009 19:33:11 +0200, a écrit : > Jeff Squyres, le Mon 21 Sep 2009 12:31:41 -0400, a écrit : > > On Sep 21, 2009, at 10:42 AM, Samuel Thibault wrote: > > >It's part of the language starting from C99 only. An application could > > >enable non-C99 mode where it becomes undefined, you can never know. > > > > That is a decade old, no? ;-) > > Yes, but existing software tends to still not evolve. I'm still seeing > software using the old termio interface while it dates at least back it = termios, the newer one > 1988. Samuel
Re: [hwloc-devel] last API possible changes
Jeff Squyres, le Mon 21 Sep 2009 12:31:41 -0400, a écrit : > On Sep 21, 2009, at 10:42 AM, Samuel Thibault wrote: > >It's part of the language starting from C99 only. An application could > >enable non-C99 mode where it becomes undefined, you can never know. > > That is a decade old, no? ;-) Yes, but existing software tends to still not evolve. I'm still seeing software using the old termio interface while it dates at least back 1988. > (Sorry -- I wasn't trying to be a jerk; just trying to be thorough...) No problem. Actually, I had followed your reasoning at the time I wrote that part of the code, I'm just repeating what I've thought in my head at the time :) > Is it possible that our use of restrict in cpuset- > bits.h could come to a conclusion that is different than the > underlying compiler (e.g., the underlying compiler needs __restrict)? I'm not sure to understand what you mean. What could happen is that gcc stops understanding __restrict while it has been understanding it since 2.95; I doubt that will ever happen. Another very low-probability possibility to get something wrong is if a compiler defines __STDC_VERSION__ to a value greater than 199901L but doesn't accept restrict; that would really be a compiler bug. The last possibility is restrict being #defined to something not being the standard restrict qualifier. I've just dropped the #if defined restrict part to avoid it, that's not a big loss. > Alternatively, is the restrict optimization really worth it here? Re-reading what we use it for at the moment, there is not many optimizations to be done, but now that I've removed the only case that could be problematic, it shouldn't be a problem. Samuel
Re: [hwloc-devel] last API possible changes
On Sep 21, 2009, at 10:42 AM, Samuel Thibault wrote: It's part of the language starting from C99 only. An application could enable non-C99 mode where it becomes undefined, you can never know. That is a decade old, no? ;-) > Alternatively, this whole block in cpuset-bits.h could be wrapped in > an "#ifndef restrict", right?: That will work only if libraries possibly defining restrict and included after hwloc do the same. You may argue that then it's their matter. The only library I see defining restrict in my /usr/include does it without #ifndef restrict, I'm not sure we want to fight this. Ok, fair enough. (Sorry -- I wasn't trying to be a jerk; just trying to be thorough...) You may not be able to resolve the difference: depending on the kind of detection of the compiler etc. etc. you may end up with restrict defined to __restrict or to something else. And as soon as one improves its detection of the compiler, the other(s!) will have to harmonize, etc. Not really sustainable. Also fair enough. Is it possible that our use of restrict in cpuset- bits.h could come to a conclusion that is different than the underlying compiler (e.g., the underlying compiler needs __restrict)? I'm somewhat dubious of that this could happen, though -- don't all modern compilers support "restrict"? (I have not looked into this recently myself; all that data has been swapped out of my brain...) Alternatively, is the restrict optimization really worth it here? If there are potential incompatibilities, perhaps the easiest answer is just to remove its use...? -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] last API possible changes
Jeff Squyres, le Mon 21 Sep 2009 10:04:21 -0400, a écrit : > On Sep 21, 2009, at 9:40 AM, Samuel Thibault wrote: > >> So it should be ok to use AC_C_RESTRICT then, right? > > > >But then we can't expose restrict in installed headers since we don't > >know _whether_ and how it is defined. > > > > Understood, but is that really our problem? "restrict" is part of the > C language, so portable applications should be able to handle it in > headers that they import, right? It's part of the language starting from C99 only. An application could enable non-C99 mode where it becomes undefined, you can never know. > Alternatively, this whole block in cpuset-bits.h could be wrapped in > an "#ifndef restrict", right?: That will work only if libraries possibly defining restrict and included after hwloc do the same. You may argue that then it's their matter. The only library I see defining restrict in my /usr/include does it without #ifndef restrict, I'm not sure we want to fight this. Anyway, #defining restrict in an installed header means that we'd have to copy the autoconf stuff into it anyway as to my knowledge autoconf is not flexible enough to only output that to some config.h.in header. That hence doesn't buy ourself much compared to the current situation, except that we'd have restrict instead of __hwloc_restrict. Risking conflicts on the definition of restrict just for that seems too much to me. > >> So I'd call it a "feature" if hwloc defines "restrict" to one thing > >> and then some other header file defines it to another. :-) > > > >? > >That would make applications get a warning just because they are for > >instance using at the same time two libraries which both define > >restrict > >to different things. > > > > Yes -- and that's a Bad Thing. The differences between those two > libraries should be resolved, lest unexpected things occur because of > a mismatch between what the header exports (and might be redefined) > and what the compiled back-end library expects, no? You may not be able to resolve the difference: depending on the kind of detection of the compiler etc. etc. you may end up with restrict defined to __restrict or to something else. And as soon as one improves its detection of the compiler, the other(s!) will have to harmonize, etc. Not really sustainable. Samuel
Re: [hwloc-devel] last API possible changes
On Sep 21, 2009, at 9:40 AM, Samuel Thibault wrote: > So it should be ok to use AC_C_RESTRICT then, right? But then we can't expose restrict in installed headers since we don't know _whether_ and how it is defined. Understood, but is that really our problem? "restrict" is part of the C language, so portable applications should be able to handle it in headers that they import, right? Alternatively, this whole block in cpuset-bits.h could be wrapped in an "#ifndef restrict", right?: #if (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95)) # define __hwloc_restrict __restrict #else # if defined restrict || __STDC_VERSION__ >= 199901L # define __hwloc_restrict restrict # else # define __hwloc_restrict # endif #endif > So I'd call it a "feature" if hwloc defines "restrict" to one thing > and then some other header file defines it to another. :-) ? That would make applications get a warning just because they are for instance using at the same time two libraries which both define restrict to different things. Yes -- and that's a Bad Thing. The differences between those two libraries should be resolved, lest unexpected things occur because of a mismatch between what the header exports (and might be redefined) and what the compiled back-end library expects, no? > But then again, Autoconf has a *very strict* policy that generated > config.h files are supposed to be private to the application that it > is building. OMPI, for example, does *not* have mpi.h include our > generated config.h. Instead, our mpi.h has a small number of things > set from configure that are required (e.g., size of bool, etc.). That's why we have both autoheader-generated hwloc/include/private/config.h.in and manually-written hwloc/include/hwloc/config.h.in Um; right. I should have known that. :-) -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] last API possible changes
Jeff Squyres, le Mon 21 Sep 2009 09:28:04 -0400, a écrit : > >Note btw that the autoconf license makes an exception for code output > >from autoconf scripts, the GPL doesn't apply to them, there is > >“unlimited permission to copy, distribute, and modify” it. > > > > Yes, but that doesn't include the raw m4 that is included in the AC > source. IANAL, but my understanding is that if you copy the raw m4, > that's taint. If you copied the raw output (e.g., copied the relevant > sh script portions from a generated "configure" script), then you'd be > ok. That's what I meant. > But that doesn't seem like a safe thing to do, given that various > m4 definitions that are contained in that "configure" script may or > may not remain compatible with future versions of the autotools I wouldn't have copied something that isn't self-contained. > >> Would it ever be sane to use one value of restrict in hwloc and a > >> different value in an upper-level application? > > > >That's not a problem since it's just an optimization & validity > >checking > >qualifier. > > So it should be ok to use AC_C_RESTRICT then, right? But then we can't expose restrict in installed headers since we don't know _whether_ and how it is defined. > FWIW, no compiler that I've ever tested complains about the following: > > #define foo bar > #define foo bar Yes. > Some (all?) compilers *will* warn if the subsequent definitions are > different, like this: > > #define foo bar > #define foo barbar Yes. > So I'd call it a "feature" if hwloc defines "restrict" to one thing > and then some other header file defines it to another. :-) ? That would make applications get a warning just because they are for instance using at the same time two libraries which both define restrict to different things. > But then again, Autoconf has a *very strict* policy that generated > config.h files are supposed to be private to the application that it > is building. OMPI, for example, does *not* have mpi.h include our > generated config.h. Instead, our mpi.h has a small number of things > set from configure that are required (e.g., size of bool, etc.). That's why we have both autoheader-generated hwloc/include/private/config.h.in and manually-written hwloc/include/hwloc/config.h.in Samuel
Re: [hwloc-devel] last API possible changes
On Sep 21, 2009, at 9:15 AM, Samuel Thibault wrote: > >Our __hwloc_restrict macro is actually a copy/paste of AC_C_RESTRICT's > >tinkering. Ah, wait, no, I'm mistaking with something else in another project. Looking closer, this definition is mine. Whew! :-) Note btw that the autoconf license makes an exception for code output from autoconf scripts, the GPL doesn't apply to them, there is “unlimited permission to copy, distribute, and modify” it. Yes, but that doesn't include the raw m4 that is included in the AC source. IANAL, but my understanding is that if you copy the raw m4, that's taint. If you copied the raw output (e.g., copied the relevant sh script portions from a generated "configure" script), then you'd be ok. But that doesn't seem like a safe thing to do, given that various m4 definitions that are contained in that "configure" script may or may not remain compatible with future versions of the autotools (e.g., mixing that sh code with sh code generated from future versions of the autotools may or may not work). But thankfully, this issue is moot. :-) > Would it ever be sane to use one value of restrict in hwloc and a > different value in an upper-level application? That's not a problem since it's just an optimization & validity checking qualifier. So it should be ok to use AC_C_RESTRICT then, right? FWIW, no compiler that I've ever tested complains about the following: #define foo bar #define foo bar Some (all?) compilers *will* warn if the subsequent definitions are different, like this: #define foo bar #define foo barbar So I'd call it a "feature" if hwloc defines "restrict" to one thing and then some other header file defines it to another. :-) But then again, Autoconf has a *very strict* policy that generated config.h files are supposed to be private to the application that it is building. OMPI, for example, does *not* have mpi.h include our generated config.h. Instead, our mpi.h has a small number of things set from configure that are required (e.g., size of bool, etc.). -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] last API possible changes
Jeff Squyres, le Mon 21 Sep 2009 08:51:35 -0400, a écrit : > On Sep 21, 2009, at 8:44 AM, Samuel Thibault wrote: > > >> FWIW, is there a reason we're not using AC_C_RESTRICT in > >> configure.ac? This allows you to use "restrict" in C code > >everywhere; > >> it'll be #defined to something acceptable by the compiler if > >> "restrict" itself is not. > > > >Our __hwloc_restrict macro is actually a copy/paste of AC_C_RESTRICT's > >tinkering. Ah, wait, no, I'm mistaking with something else in another project. Looking closer, this definition is mine. Note btw that the autoconf license makes an exception for code output from autoconf scripts, the GPL doesn't apply to them, there is “unlimited permission to copy, distribute, and modify” it. > >The problem is precisely that AC_C_RESTRICT provides "restrict", > >and not another keyword, so that using it in installed headers > >may conflict with other headers' tinkering about restrict. Yes, > >configure is meant to detect such kind of things, but it can not > >know which variety of headers the user will want to include from > >its application, and any of them could want to define restrict to > >something else. > > Would it ever be sane to use one value of restrict in hwloc and a > different value in an upper-level application? That's not a problem since it's just an optimization & validity checking qualifier. Samuel
Re: [hwloc-devel] last API possible changes
On Sep 21, 2009, at 8:44 AM, Samuel Thibault wrote: > FWIW, is there a reason we're not using AC_C_RESTRICT in > configure.ac? This allows you to use "restrict" in C code everywhere; > it'll be #defined to something acceptable by the compiler if > "restrict" itself is not. Our __hwloc_restrict macro is actually a copy/paste of AC_C_RESTRICT's tinkering. Er... that's a license violation, right? Doesn't that taint hwloc into making it GPL? (good thing we haven't released yet!) :-( The problem is precisely that AC_C_RESTRICT provides "restrict", and not another keyword, so that using it in installed headers may conflict with other headers' tinkering about restrict. Yes, configure is meant to detect such kind of things, but it can not know which variety of headers the user will want to include from its application, and any of them could want to define restrict to something else. Would it ever be sane to use one value of restrict in hwloc and a different value in an upper-level application? -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] last API possible changes
Jeff Squyres, le Mon 21 Sep 2009 08:22:06 -0400, a écrit : > FWIW, is there a reason we're not using AC_C_RESTRICT in > configure.ac? This allows you to use "restrict" in C code everywhere; > it'll be #defined to something acceptable by the compiler if > "restrict" itself is not. Our __hwloc_restrict macro is actually a copy/paste of AC_C_RESTRICT's tinkering. The problem is precisely that AC_C_RESTRICT provides "restrict", and not another keyword, so that using it in installed headers may conflict with other headers' tinkering about restrict. Yes, configure is meant to detect such kind of things, but it can not know which variety of headers the user will want to include from its application, and any of them could want to define restrict to something else. Samuel
Re: [hwloc-devel] last API possible changes
On Sep 20, 2009, at 6:12 PM, Samuel Thibault wrote: > Also, we have __hwloc_restrict everywhere in the public API, but also in > the manpages? Should we convert the latter into a regular "restrict" > keyword ? I had tried before already through the .cfg and that didn't work. Since we now have our own Makefile rules, I've just added a sed call, which also does the same for inline btw. FWIW, is there a reason we're not using AC_C_RESTRICT in configure.ac? This allows you to use "restrict" in C code everywhere; it'll be #defined to something acceptable by the compiler if "restrict" itself is not. -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] last API possible changes
Brice Goglin, le Thu 17 Sep 2009 09:50:57 +0200, a écrit : > * Do we actually need hwloc_get_type_order() or would > hwloc_compare_types() be enough? I can't find any example where some > type "orders" is not used for direct comparison. And the latter is probably clearer, indeed. > * I think the _above_cpuset() and _below_cpuset() function names are not > very clear. I think "inside" may be better that "below" (and rename > get_cpuset_objs into get_objs_inside_cpuset as well and move it nearby). > And maybe use "covering" instead of "above" since we already have > "covering" somewhere else? That should be fine, yes. > Also, we have __hwloc_restrict everywhere in the public API, but also in > the manpages? Should we convert the latter into a regular "restrict" > keyword ? I had tried before already through the .cfg and that didn't work. Since we now have our own Makefile rules, I've just added a sed call, which also does the same for inline btw. > That's all for today :) Better fix this now instead of changing the ABI > after the first hwloc release. Sure :) Samuel
