[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1] getpageframeinfo3: replace hardcoded batchsize with constant
>>> On 09.03.18 at 17:30, <george.dunlap@xxxxxxxxxx> wrote: > On 03/09/2018 04:25 PM, Jan Beulich wrote: >>>>> On 09.03.18 at 17:17, <olaf@xxxxxxxxx> wrote: >>> --- a/xen/include/public/domctl.h >>> +++ b/xen/include/public/domctl.h >>> @@ -137,6 +137,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t); >>> #define XEN_DOMCTL_PFINFO_BROKEN (0xdU<<28) /* broken page */ >>> #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28) >>> >>> +#define XEN_GETPAGEFRAMEINFO3_MAX_SIZE 1024U >> >> This is an implementation detail; it shouldn't be made part of the >> public interface. If there's a need for user land to know the value, >> and if there's currently no way to query it, that's what you >> would want to add. > > But the domctl interface isn't stable, right? There's no need to make a > flexible backwards-compatible interface between libxc and Xen; sharing a > #define should be fine, as long as there's only one place to change it. Well, strictly speaking this is an option. But I would prefer if we didn't abuse the "is not a stable interface" property, which this changes feels like it would. Furthermore it hasn't become clear to me why, if this hard coded number is deemed a problem, we don't get rid of it altogether. Domctl-s have long gained the ability to be preemptible - there various examples. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |