Re: [PATCH RFC 12/31] tools: Utility for dealing with featuresets

[Ian Campbell <ian.campbell@citrix.com>]

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.