Code cleanups sometimes expose fundamental disagreements about how the code
should look; here some veteran kernel hackers show how it's done.
Rusty, in his peevish way, complained that macros defining
constants should have a name which somewhat accurately reflects the
actual purpose of the constant.
Aside from the fact that PTE_MASK gives no clue as to what's actually
being masked, and is misleadingly similar to the functionally entirely
different PMD_MASK, PUD_MASK and PGD_MASK, I don't really see what the
-- Jeremy Fitzhardinge
Has Rusty ever heard about the economy of the healthy flow of
incoming regressions? What will we do without obscure names and
hard to find bugs? First he writes a simple and readable hypervisor
(ruining a whole industry based on obscurity!) and now that. It's
_so_ unamerican and unaustralian. I'm worried.
-- Ingo Molnar
I am disgusted with this inappropriate emphasis on clarity over
obscurity. It should be pretty clear to everyone here that we
can't have both! Fortunately, there is a way to partially rectify
the situation. Ingo, please apply.
+/* There's something suspicious about this line: see PTE_PFN_MASK comment. */
#define __PHYSICAL_MASK ((phys_addr_t)(1ULL << __PHYSICAL_MASK_SHIFT) - 1)
@@ -19,6 +20,7 @@
/* PTE_PFN_MASK extracts the PFN from a (pte|pmd|pud|pgd)val_t */
+/* This line is quite subtle. See __PHYSICAL_MASK comment above. */
#define PTE_PFN_MASK ((pteval_t)PHYSICAL_PAGE_MASK)
-- Rusty Russell
to post comments)