All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org, randy.dunlap@oracle.com
Subject: Re: [patch 2/8] mm: merge populate and nopage into fault (fixes nonlinear)
Date: Sat, 19 May 2007 03:38:32 +0200	[thread overview]
Message-ID: <20070519013832.GD15569@wotan.suse.de> (raw)
In-Reply-To: <alpine.LFD.0.98.0705180758450.3890@woody.linux-foundation.org>

On Fri, May 18, 2007 at 08:11:35AM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 18 May 2007, akpm@linux-foundation.org wrote:
> > 
> > Nonlinear mappings are (AFAIKS) simply a virtual memory concept that encodes
> > the virtual address -> file offset differently from linear mappings.
> 
> I'm not going to merge this one.
> 
> First off, I don't see the point of renaming "nopage" to "fault". If you 
> are looking for compiler warnings, you might as well just change the 
> prototype and be done with it.

I considered that, but it is going to break a whole lot of drivers (and
I guess some out of tree code FWIW). If you want me to attempt to convert
all drivers in the tree, then...

(BTW, I agree the whole series is late, and I would have rathered it go
in -rc1).


> The new name is not even descriptive, since 
> it's all about nopage, and not about any other kind of faults.

I'm going to convert page_mkwrite over as well.


> [ Side note: why is "address" there in the fault data? It would seem that 
>   anybody that uses it is by definition buggy, so it shouldn't be there if 
>   we're fixing up the interfaces. ]

It could matter for some things... page colouring maybe.


> Also, the commentary says that you're planning on replacing "nopfn" too, 
> which means that returning a "struct page *" is wrong. So the patch is
> introducing a new interface that is already known to be broken. 
> 
> Here's a suggestion:
> 
>  - make "nopage()" return "int" (the status code). Move the "struct page" 
>    pointer into the data area, and add a "pte_t" entry there too, so that 
>    the callee can now decide to fill in one or the other (or neither, if 
>    it returns an error).

Actually, I was thinking about changing to an int return code which
makes the page_mkwrite conversion nicer too. But a pte_t? Yuck Linus!

 
>  - "struct fault_data" is a stupid name. Of *course* it is data: it's a 
>    struct. It can't be code. But it's not even about faults. It's about 
>    missing pages.
> 
>    So call it something else. Maybe just "struct nopage". Or, "struct 
>    vm_fault" at least, so that it's at least not about *random* faults.

The name doesn't bother me so much, but as I said, it is not just going
to be for missing pages. Also, keeping nopage means a full conversion,
wheras we can support nopage with a few lines of backward compatible code.

--
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:[~2007-05-19  1:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-18  7:37 [patch 2/8] mm: merge populate and nopage into fault (fixes nonlinear) akpm, Nick Piggin
2007-05-18 10:24 ` Christoph Hellwig
2007-05-18 15:11 ` Linus Torvalds
2007-05-19  1:38   ` Nick Piggin [this message]
2007-05-22 15:12   ` Christoph Hellwig
2007-05-23  1:14     ` Linus Torvalds
2007-05-23  8:35       ` David Chinner
2007-05-23  9:35         ` Nick Piggin
2007-05-23  2:57     ` Nick Piggin
2007-05-23 23:37   ` Benjamin Herrenschmidt
2007-05-24  1:48     ` Nick Piggin
2007-05-24  2:06       ` Linus Torvalds
2007-05-24  2:24         ` Nick Piggin

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=20070519013832.GD15569@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=randy.dunlap@oracle.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.