From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: RFC/Proposal: Partial `libxenctrl` API/ABI stabilisation Date: Tue, 19 May 2015 10:48:51 +0100 Message-ID: <1432028931.12989.64.camel@citrix.com> References: <1431963008.4944.80.camel@citrix.com> <555A2A16020000780007B50B@mail.emea.novell.com> <1432024819.12989.9.camel@citrix.com> <555B14FF020000780007B7D2@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <555B14FF020000780007B7D2@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, 2015-05-19 at 09:48 +0100, Jan Beulich wrote: > >>> On 19.05.15 at 10:40, wrote: > > On Mon, 2015-05-18 at 17:06 +0100, Jan Beulich wrote: > >> >>> On 18.05.15 at 17:30, wrote: > >> > `libxenctrl` today exposes many symbols which look to be internal. We > >> > should consider also reducing that set by using > >> > `__attribute__((visibility("hidden")))`. > >> > >> Or a version script? > > > > Sure, I'm not familiar with the relative merits, I suppose it's just > > white- vs blacklist. I'm happy to go whichever way people prefer. > > Version scripts allow for both white and black listing. And they > also help with retaining older version compatibility implementations > of functions having got changed in an incompatible way in a newer > version. Sounds like the way to go then. Ian.