linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: npiggin@suse.de
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hugh@veritas.com>,
	Jared Hulbert <jaredeh@gmail.com>,
	Carsten Otte <cotte@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-arch@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch 2/6] mm: introduce pte_special pte bit
Date: Fri, 18 Jan 2008 08:41:22 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.1.00.0801180816120.2957@woody.linux-foundation.org> (raw)
In-Reply-To: <20080118045755.516986000@suse.de>


On Fri, 18 Jan 2008, npiggin@suse.de wrote:
>   */
> +#ifdef __HAVE_ARCH_PTE_SPECIAL
> +# define HAVE_PTE_SPECIAL 1
> +#else
> +# define HAVE_PTE_SPECIAL 0
> +#endif
>  struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, pte_t pte)
>  {
> -	unsigned long pfn = pte_pfn(pte);
> +	unsigned long pfn;
> +
> +	if (HAVE_PTE_SPECIAL) {

I really don't think this is *any* different from "#ifdefs in code".

#ifdef's in code is not about syntax, it's about abstraction. This is 
still the exact same thing as having an #ifdef around it, and in many ways 
it is *worse*, because now it's just made to look somewhat different with 
a particularly ugly #ifdef.

IOW, this didn't abstract the issue away, it just massaged it to look 
different.

I suspect that the nicest abstraction would be to simply make the whole 
function be a per-architecture thing. Not exposing a "pte_special()" bit 
at all, but instead having the interface simply be:

 - create special entries:
	pte_t pte_mkspecial(pte_t pte)

 - check if an entry is special:
	struct page *vm_normal_page(vma, addr, pte)

and now it's not while the naming is a bit odd (for historical reasons), 
at least it is properly *abstracted* and you don't have any #ifdef's in 
code (and we'd probably need to extend that abstraction then for the 
"locklessly look up page" case eventually).

[ To make it slightly more regular, we could make "pte_mkspecial()" take 
  the vma/addr thing too, even though it would never really use it except 
  to perhaps have a VM_BUG_ON() that it only happens within XIP/PFNMAP 
  vma's.

  The "pte_mkspecial()" definitely has more to to with "vm_normal_page()"
  than with the other "pte_mkxyzzy()" functions, so it really might make
  sense to instead make the thing

	void set_special_page(vma, addr, pte_t *, pfn, pgprot) 

  because it is never acceptable to do "pte_mkspecial()" on any existent 
  PTE *anyway*, so we might as well make the interface reflect that: it's 
  not that you make a pte "special", it's that you insert a special page 
  into the VM.

  So the operation really conceptually has more to do with "set_pte()" 
  than with "pte_mkxxx()", no? ]

Then, just have a library version of the long form, and make architectures 
that don't support it just use that (just so that you don't have to 
duplicate that silly thing). So an architecture that support special page 
flags would do somethiing like

	#define set_special_page(vma,addr,ptep,pfn,prot) \
		set_pte_at(vma, addr, ptep, mk_special_pte(pfn,prot))
	#define vm_normal_page(vma,addr,pte)
		(pte_special(pte) ? NULL : pte_page(pte))

and other architectures would just do

	#define set_special_page(vma,addr,ptep,pfn,prot) \
		set_pte_at(vma, addr, ptep, mk_pte(pfn,prot))
	#define vm_normal_page(vma,addr,pte) \
		generic_vm_normal_page(vma,addr,pte)

or something.

THAT is what I mean by "no #ifdef's in code" - that the selection is done 
at a higher level, the same way we have good interfaces with clear 
*conceptual* meaning for all the other PTE accessing stuff, rather than 
have conditionals in the architecture-independent code.

It's not about syntax - it's about having good conceptual abstractions.

			Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-01-18 16:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080118045649.334391000@suse.de>
2008-01-18  4:56 ` [patch 1/6] mm: introduce VM_MIXEDMAP npiggin, Jared Hulbert
2008-01-18  4:56 ` [patch 2/6] mm: introduce pte_special pte bit npiggin
2008-01-18 16:41   ` Linus Torvalds [this message]
2008-01-18 18:04     ` Sam Ravnborg
2008-01-18 18:28       ` Linus Torvalds
2008-01-18 18:53         ` Sam Ravnborg
2008-01-18 22:46     ` Nick Piggin
2008-01-18 23:03       ` Linus Torvalds
2008-01-19  5:07         ` Nick Piggin
2008-01-21  9:43       ` Nick Piggin
2008-01-18  4:56 ` [patch 3/6] mm: add vm_insert_mixed npiggin
2008-01-18  4:56 ` [patch 4/6] xip: support non-struct page backed memory npiggin
2008-03-01  8:14   ` Jared Hulbert
2008-03-03  5:29     ` Nick Piggin
2008-03-03  8:30       ` Carsten Otte
2008-03-03 15:59       ` Jared Hulbert
2008-03-03  8:18     ` Carsten Otte
2008-03-03 15:44       ` Jared Hulbert
2008-03-03 18:40       ` Linus Torvalds
2008-03-03 19:38         ` Jared Hulbert
2008-03-03 20:04           ` Linus Torvalds
2008-03-03 20:32             ` Nick Piggin
2008-03-03 22:21               ` Linus Torvalds
2008-03-03 23:25                 ` Jared Hulbert
2008-03-04  9:06                 ` Carsten Otte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.1.00.0801180816120.2957@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=cotte@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hugh@veritas.com \
    --cc=jaredeh@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox