On 06/01/2020 11:28, George Dunlap wrote: > 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?
It can be explained with a picture (attached) ;) > > 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
