linux-kernel - Re: [PATCH 1/2] x86: rename PTE_MASK to PTE_PFN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080722115540.GA26178@elte.hu>
Date:	Tue, 22 Jul 2008 13:55:40 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] x86: rename PTE_MASK to PTE_PFN_MASK


* Rusty Russell <rusty@...tcorp.com.au> wrote:

> On Tuesday 22 July 2008 18:36:26 Ingo Molnar wrote:
> > * Jeremy Fitzhardinge <jeremy@...p.org> wrote:
> > > Rusty, in his peevish way, complained that macros defining constants
> > > should have a name which somewhat accurately reflects the actual
> > > purpose of the constant.
> >
> > Applied to tip/x86/cleanups anyway. Rusty will find out himself how bad
> > this whole concept of clean and understandable code is, soon enough!
> 
> 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)

>  /* 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)

Now that you and Jeremy have thoroughly destroyed this file's obscurity 
with your disgusting cleanups and clarifications, i fear it's beyond 
repair. No matter how much i'd love to apply this infinitely recursive 
piece of documentation (what a genius it takes to even think of it!) i 
regret that i cannot. So sad.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/