Either name would be fine; PINT_ is a little better I suppose.
Rob
Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Wed, 22 Feb 2006 10:10 -0500:
It appears that compile errors I'm running into with PVFS2 and
Silverstorm/Mellanox infiniband are definitions in the ib code that
duplicate definitions in kernel headers. Specifically:
#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)
Do you think it may be appropriate to call these
PVFS2_likely and PVFS2_unlikely to avoid name collisions with kernel
#defines? We could also test for their existince, though then we
couldn't be certain what the macro did exactly. Any strong opinions?
None of the IB code interacts with the kernel code, but I guess the
Silverstorm userspace IB headers must either pull in kernel headers
(blecch) or define likely() for their own purposes.
I agree renaming those functions in the pvfs2 IB code is the way to
go. Perhaps a naming guru could suggest if we should change them
to
PVFS2_likely
PVFS2_unlikely
as you suggest or would prefer
PINT_likely
PINT_unlikely
or even something to keep it BMI-specific?
It's just an optimization to help the compiler with branch
prediction. I try only to use it for assert-like things where the
likelihood of the outcome is really obvious.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
