On 30/07/2019 12:26, Jan Beulich wrote: > On 29.07.2019 14:12, Andrew Cooper wrote: >> --- a/xen/include/xen/nodemask.h >> +++ b/xen/include/xen/nodemask.h >> @@ -11,7 +11,9 @@ >> * The available nodemask operations are: >> * >> * void node_set(node, mask) turn on bit 'node' in mask >> + * void __nodemask_set(node, mask) turn on bit 'node' in mask (unlocked) >> * void node_clear(node, mask) turn off bit 'node' in mask >> + * void __nodemask_clear(node, mask) turn off bit 'node' in mask >> (unlocked) > To be honest I'm unhappy to see you introduce new name space > violations. I realize you want to have the node mask interfaces > match the CPU mask one as closely as possible, but I think we > should diverge here (and eventually make the CPU mask ones > follow whatever route we go here). As to naming, since these > are static inlines, a single leading underscore may be an > option (albeit I'd prefer to avoid this). Another option would > be to have double infix underscores (nodemask__set()). Yet > another option would be to express the non-atomicity in a > verbal way rather than by the number of underscores used. I'm > afraid I don't have a good naming suggestion in that case, > though.
I'm really not as concerned with namespace violations as you seem to be. We are not a library having to cooperate with arbitrary others - we are a freestanding build with the compiler being the only other source of symbols in the namespace. Our chances of colliding are very low to begin with, and fixing conflicts if they arise is trivial. As you note, there is nothing obvious as an alternative. The double infix is a no-go as far as I'm concerned - it's far too subtle in the code. Ergo, consistency with cpumask and the bitops is the winning factor here. At some point in the future if an alternative is chosen, it will want changing consistently throughout the tree. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
