On 12/19/19 11:15 PM, Andrew Cooper wrote: > On 19/12/2019 11:35, Jan Beulich wrote: >>>>> XENVER_changeset >>>>> XENVER_commandline >>>>> XENVER_build_id >>>>> >>>>> Return a more customer friendly empty string instead of "<denied>" >>>>> which would be shown in tools like dmidecode.> >>>> I think "<denied>" is quite fine for many of the original purposes. >>>> Maybe it would be better to filter for this when populating guest >>>> DMI tables? >>> I don't know how DMI tables are populated, but nothing stops a guest >>> from using these hypercalls directly. >> And this is precisely the case where I think "<denied>" is better >> than an empty string. > > "<denied>" was a terrible choice back when it was introduced, and its > still a terrible choice today. > > These are ASCII string fields, and the empty string is a perfectly good > string. Nothing is going to break, because it would have broken the > first time around. > > The end result without denied sprayed all over this interface is much > cleaner overall.
Unfortunately this mail doesn't contain any facts or arguments, just unsubstantiated value judgements. What's so terrible about "<denied>" -- what bad effect does it have? Why is "" better / cleaner? One negative effect of returning "" is that if you have a tool which doesn't check the value but just dumps it into a log somewhere, then the log just contains nothing at all. A log which contains "<denied>" makes it clear to the person reading it that something has been hidden on purpose. You can totally imagine someone wasting several hours trying to figure out why their logging isn't working, only to discover that it is working, but that it was just logging an empty string. And is it so bad for dmidecode to return something like "<denied>" in that case? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
