Brice Goglin wrote:
> Then, VERSION1_COMPATIBILITY should be prefixed with NUMA_ or so to
> avoid namespace collision.
>
> And, finally, how are we supposed to support old and new libnuma version
> in our end application? Supporting only API 2 isn't possible so early.
> Is there something we can check and that you guys guarantee to not break
> in the future? It would be nice to have something like #define
> LIBNUMA_API_VERSION 2 in numa.h so that we can check it at compile time.
>
Also, the v1 API compatibility doesn't seem to work:
In the v1 API, you could call numa_node_on_cpus() with any buffer
length. Now, if you install v2 and define VERSION1_COMPATIBILITY, your
v1 call is translated into a v2 call. However, the v2 function
internally creates a v2 buffer, with a fixed 64bits buffer length. So if
you don't use a 64bits buffer in the v1 API, the second call to
numa_node_on_cpus() fails with:
map size mismatch; abort
: Invalid argument
because buffer->size is 32 while the internal
node_cpu_mask_v2[node]->size is 64 in:
if (node_cpu_mask_v2[node]) {
/* have already constructed a mask for this node */
if (buffer->size != node_cpu_mask_v2[node]->size) {
Is this fixable?
So far, the v1 API doesn't work anymore here if v2 is installed. We
could upgrade our application to the v2 API but we have many users that
will likely not upgrade their distro to libnuma v2 soon, so that's not
acceptable for now.
So I still suggest that you add a #define LIBNUMA_VERSION 2 to numa.h so
that we can check at compile which libnuma we are using and support both
until everybody installs v2.
thanks!
Brice
PS: Is there a SVN or GIT repo somewhere?
--
To unsubscribe from this list: send the line "unsubscribe linux-numa" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
