linux-numa.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

From: Scott Lurndal <scott.lurndal@3leafsystems.com>
To: linux-numa@vger.kernel.org
Subject: Library versioning issues.
Date: Tue, 9 Feb 2010 13:48:30 -0800	[thread overview]
Message-ID: <20100209214830.GA23942@pendragon.3leafnetworks.com> (raw)


Hi,

  I've a third-party application that's designed to be NUMA aware when
running on a NUMA system, but since this application also runs on non-NUMA
systems and a wide variety of operating systems, they don't link the
application directly with the libnuma shared object.   Instead, they use
dlopen() to open the library at run-time, if it exists.

  The issue is that the application expects the 1.0 interfaces, however the
run time linker dlsym() is returning a function pointer to the _v2 interface
for numa_node_to_cpus_v2, thus the call fails and the application believes
that there is no NUMA configuration available.

  We've fixed this internally (and temporarily) with the patch below,
but would like some guidance as to a longer-term fix that accomodates
applications that use dlopen to access libnuma and preserves versioning
so that older applications will continue to function correctly.

  Perhaps the API for a given function should not change, but rather
new functions should be implemented and the older deprecated?

  thanks,

scott

$ cvs -q diff -ub -r1.1 -r1.2 libnuma.c
Index: libnuma.c
===================================================================
RCS file: /home/slurndal/cvs/opensource/numactl/libnuma.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -b -r1.1 -r1.2
--- libnuma.c   6 Feb 2010 01:18:32 -0000       1.1
+++ libnuma.c   6 Feb 2010 01:23:12 -0000       1.2
@@ -1240,7 +1240,7 @@
        }
        return err;
 }
-__asm__(".symver numa_node_to_cpus_v1,numa_node_to_cpus@libnuma_1.1");
+__asm__(".symver numa_node_to_cpus_v2,numa_node_to_cpus@libnuma_1.1");
 
 /*
  * test whether a node has cpus
@@ -1316,7 +1316,7 @@
        } 
        return err; 
 }
-__asm__(".symver numa_node_to_cpus_v2,numa_node_to_cpus@@libnuma_1.2");
+__asm__(".symver numa_node_to_cpus_v1,numa_node_to_cpus@@libnuma_1.2");
 
 make_internal_alias(numa_node_to_cpus_v1);
 make_internal_alias(numa_node_to_cpus_v2);

next             reply	other threads:[~2010-02-09 21:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-09 21:48 Scott Lurndal [this message]
2010-02-10  7:34 ` Library versioning issues Andi Kleen
2010-02-10 12:45   ` Library versioning issues II Andi Kleen
2010-02-10 19:28     ` Scott Lurndal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100209214830.GA23942@pendragon.3leafnetworks.com \
    --to=scott.lurndal@3leafsystems.com \
    --cc=linux-numa@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).