> On Jan 11, 2020, at 4:02 AM, Doug Goldstein <car...@cardoe.com> wrote: > > > > On 1/10/20 4:37 AM, Sergey Dyasli wrote: >> Hide the following information that can help identify the running Xen >> binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset. >> Add explicit cases for XENVER_commandline and XENVER_build_id as well. >> Introduce xsm_filter_denied() to hvmloader to remove "<denied>" string >> from guest's DMI tables that otherwise would be shown in tools like >> dmidecode. >> Signed-off-by: Sergey Dyasli <sergey.dya...@citrix.com> >> --- >> v1 --> v2: >> - Added xsm_filter_denied() to hvmloader instead of modifying xen_deny() > > So 100% this version of the patch won't fly with the various downstreams that > run the v1 of this patch. Those various consumers will stick with v1. > > If the goal of this is to reduce the burden of the downstreams and their > customers to carry a patch against Xen then I wouldn't even bother with this > version.
If the goal is to come up with a solution that works for everyone, it would be helpful if you said *why* “various consumers” would find this patch unacceptable; and also what they might think about the alternate solutions proposed (and why). -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
