From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH RFC 12/31] tools: Utility for dealing with featuresets Date: Wed, 6 Jan 2016 10:38:44 +0000 Message-ID: <1452076724.7292.24.camel@citrix.com> References: <1450301073-28191-1-git-send-email-andrew.cooper3@citrix.com> <1450301073-28191-13-git-send-email-andrew.cooper3@citrix.com> <1452007066.13361.315.camel@citrix.com> <568BEBDB.1070803@citrix.com> <1452011642.13361.371.camel@citrix.com> <568BF9B0.6030600@citrix.com> <1452015469.16082.15.camel@citrix.com> <568C05B9.1030104@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <568C05B9.1030104@citrix.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: Andrew Cooper , Xen-devel Cc: Wei Liu , Ian Jackson List-Id: xen-devel@lists.xenproject.org On Tue, 2016-01-05 at 18:04 +0000, Andrew Cooper wrote: > On 05/01/16 17:37, Ian Campbell wrote: > > On Tue, 2016-01-05 at 17:13 +0000, Andrew Cooper wrote: > > > They are: SHARED_1d, known_features[], inverted_features[], > > > {pv,hvm_shadow,hvm_hap}_featuremask[], struct tagged_featureset, > > > deep_deps[], nr_deep_deps, deep_dep_features[] and > > > lookup_deep_deps(). > > Which ones of these are expected to be consumed by > > applications/utilities > > using libxc as well as shared between Xen and libxc? > > libxc uses all the deep_deps, but only as an internal implementation > detail of xc_cpuid_apply_policy() I'm not interested in what libxc uses internally. I'm interested only in what things which link against libxc, which includes you debug utility, are using directly themselves (i.e. not via a libxc call). > I do not expect anything from cpuid-private.h to be exposed in the libxc > API, although by the looks of it, the symbols are actually present in > libxenctrl.so Yes, this is because we don't enforce technically whether symbols are exported or not (maybe I should write a map file which only allows xc_* and see what breaks...). Our closest analogue to whether something is exported vs private is "are they used outside of tools/libxc", e.g. by tools/misc or tools/libxl, and we have been explicitly annotating in-tree users of what we consider libxc internals by such components, see e.g. tools/misc/Makefile and elsewhere which have comments like: # xen-hptool incorrectly uses libxc internals. Around the point they arrange for CFLAGS to point into internal stuff etc. Your new tool is either adding a public API to libxc or adding another instance of incorrectly using libxc internals. I don't think we want to add any more of the latter, and certainly not without the caveats we apply to other such cases (i.e. the comment to indicate that it is doing something naughty). Ian.