Re: [Xen-devel] [PATCH for-4.13] xen: Drop bogus BOOLEAN definitions, TRUE and FALSE

[Jan Beulich <jbeulich@suse.com>]

On 12.11.2019 14:39, Andrew Cooper wrote:
> On 12/11/2019 08:35, Jan Beulich wrote:
>> On 11.11.2019 21:24, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/x86_64/mm.c
>>> +++ b/xen/arch/x86/x86_64/mm.c
>>> @@ -1077,7 +1077,7 @@ long do_set_segment_base(unsigned int which, unsigned long base)
>>>  }
>>>  
>>>  
>>> -/* Returns TRUE if given descriptor is valid for GDT or LDT. */
>>> +/* Returns true if given descriptor is valid for GDT or LDT. */
>>>  int check_descriptor(const struct domain *dom, seg_desc_t *d)
>> Wouldn't changes like this one better be accompanied by also adjusting
>> the return type of the function (there are more examples further down
>> in common/timer.c)?
> 
> No.  That is an unrelated change.
> 
> If I were flush with free time then I might consider doing this and
> substantially increase the test burden.
> 
> As it stands, this request is scope creep.

The other alternative would have been to ask for scope reduction,
i.e. leave alone such comments (to avoid the resulting visual
disconnect between comment and actual data type). Anyway - it was
just a question I wanted to raise, not a request for further work
on your part.

>>> --- a/xen/include/asm-arm/arm64/efibind.h
>>> +++ b/xen/include/asm-arm/arm64/efibind.h
>>> @@ -107,7 +107,7 @@ typedef uint64_t   UINTN;
>>>  #define POST_CODE(_Data)
>>>  
>>>  
>>> -#define BREAKPOINT()        while (TRUE);    // Make it hang on Bios[Dbg]32
>>> +#define BREAKPOINT()        while (true);    // Make it hang on Bios[Dbg]32
>> You do realize that this and other EFI headers (and perhaps also
>> ACPI ones) are largely verbatim imports from other projects,
>> updating of which will become less straightforward by such
>> replacements? When pulling in the EFI ones I intentionally did not
>> fiddle with them more than absolutely necessary.
> 
> Yes, and?
> 
> It is unacceptable for the acpi headers to forcibly redefine anything in
> their scope, and its definition of va_args is downright dangerous.
> 
> All junk like this in header files does nothing but waste space and
> compiler effort during compilation, and leave people with an slim chance
> of shooting themselves in the foot.

Well, on one hand I'm with you. But then I dare to guess that the
people having written the headers the way they are also aren't
completely un-knowledgeable, i.e. did so for a reason. This seems
(I'm sorry to say it this bluntly) once again a case where you
appear to not be willing to accept other thinking than your own.
It is therefore one thing to get rid of TRUE/FALSE _outside_ of
such headers (where it would better never have been introduced),
and another to modify these more or less verbatim imported headers
themselves.

> How many times do these get touched?  (Rhetorical question.  The answer
> is once (me, clang build fix) since their introduction, 8, 9 and 10
> years ago).
> 
> For the 30s of effort required to tweak once-in-a-blue-moon patches
> which touch these headers, trimming the junk is a no-brainer.

Well, I agree that for just _this_ change it's not a big deal.
But any such approach doesn't scale: What we allow ourselves to do
once we may then easily allow ourselves to do another time, and
then dozens more times. Once that has happened, the effort needed
to do a re-sync may become non-negligible.

Bottom line - I'm half convinced and willing to give my ack, but
I'm not convinced you truly thought through the longer term
consequences. I'd therefore be far happier to see this patch
split into a non-controversial part (anything that's not tied to
the ACPI and EFI header imports), an ACPI, and an EFI part.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel