On 12/11/2019 14:03, Jan Beulich wrote: > 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.
Just because there may have been a reason, doesn't mean the reason is compatible with Xens codebase, today. > 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. I might not care if this was confined to a private.h in a subdirectly which was never edited. But it is not. The actively dangerous constructs in these header files are included all over the Xen codebase, just waiting to shoot someone in the foot. Xen is not bound by whatever decisions these projects made more than a decade ago. We do not need to take the headers verbatim, and there are good reasons to specifically not take them verbatim. > 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. The fact that their use has crept outside demonstrates why they should be deleted entirely. The constructs are buggy, and the will creep again in the future. Turning TRUE/FALSE/BOOL into a compile error is by far the best way to increase the health of the codebase. >> 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. There are perfectly easy ways to do this with negligible effort, as I frequently do with other routine XenServer work. (The git locally-modified tracking is especially good for this, even for pulling a small delta out of a substantially modified file.) > 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. I do not want to writing the same patch again in $N years time because review and CI missed it creeping back in. I don't think this is an unreasonable position to take. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
