From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261586AbUKONR2@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261586AbUKONR2 (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 15 Nov 2004 08:17:28 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261589AbUKONR2
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 15 Nov 2004 08:17:28 -0500
Received: from mx1.redhat.com ([66.187.233.31]:47031 "EHLO mx1.redhat.com")
	by vger.kernel.org with ESMTP id S261586AbUKONRZ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 15 Nov 2004 08:17:25 -0500
From: David Howells <dhowells@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0411132105240.12386@ppc970.osdl.org> 
References: <Pine.LNX.4.58.0411132105240.12386@ppc970.osdl.org>  <20041112023817.247af548.akpm@osdl.org> <20041111143148.76dcaba4.akpm@osdl.org> <200411081432.iA8EWfmh023432@warthog.cambridge.redhat.com> <19844.1100255635@redhat.com> <20942.1100257558@redhat.com> 
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>, davidm@snapgear.com,
       linux-kernel@vger.kernel.org, uclinux-dev@uclinux.org
Subject: Re: [PATCH] VM routine fixes 
User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 15 Nov 2004 13:14:59 +0000
Message-ID: <26123.1100524499@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


> > vm_area_struct not having an ops member? There's no real need for ops on
> > uClinux since almost all of the ops are irrelevant.
> 
> I don't think that is a valid argument.
> 
> If uClinux wants to be a different source-base, then go wild. But if you 
> want to integrate into the standard kernel, there are other priorities. 
> One of them is that it has to integrate cleanly. And that means that we 
> don't do micro-optimizations that make the non-MMU case affect mainline 
> code unless there is a damn good reason.

So not having an MMU, page tables or PTEs or any requirement for operations
that act upon them is not enough?

Do you then want me to use the MMU version of struct vm_area_struct for both
MMU and !MMU? It can be done, almost. I'll need to add one member variable (a
refcount).

David