Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751021AbWBOGJi (ORCPT ); Wed, 15 Feb 2006 01:09:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751025AbWBOGJi (ORCPT ); Wed, 15 Feb 2006 01:09:38 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70]:56966 "EHLO sj-iport-1.cisco.com") by vger.kernel.org with ESMTP id S1751018AbWBOGJh (ORCPT ); Wed, 15 Feb 2006 01:09:37 -0500 To: Nick Piggin Cc: "Michael S. Tsirkin" , Andrew Morton , Hugh Dickins , William Irwin , Gleb Natapov , Benjamin Herrenschmidt , Linux Kernel Mailing List , openib-general@openib.org, Petr Vandrovec , Badari Pulavarty , Grant Grundler , Matthew Wilcox Subject: Re: [PATCH] madvise MADV_DONTFORK/MADV_DOFORK X-Message-Flag: Warning: May contain useful information References: <20060213154114.GO32041@mellanox.co.il> <20060213210906.GC13603@mellanox.co.il> <20060213225538.GE13603@mellanox.co.il> <20060213233517.GG13603@mellanox.co.il> <43F2AEAE.5010700@yahoo.com.au> From: Roland Dreier Date: Tue, 14 Feb 2006 22:09:34 -0800 In-Reply-To: <43F2AEAE.5010700@yahoo.com.au> (Nick Piggin's message of "Wed, 15 Feb 2006 15:31:42 +1100") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-OriginalArrivalTime: 15 Feb 2006 06:09:35.0883 (UTC) FILETIME=[655B35B0:01C631F6] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1219 Lines: 26 Nick> May I ask, what is the rationale for ignoring the apparent Nick> conventions of all architectures? For example parisc, you Nick> appear to even go contrary to the comment. Looking through include/asm-*/mman.h, I have to agree. The parisc example seemly especially bad, as (in addition to being in the reserved range as Nick notes) the DONTFORK/DOFORK values are stuck in a block with the page size values instead of the previous block where they seem more sensible. However, in other files like the alpha version, where the rest of the values are in decimal, the hex defines look rather jarring. Michael, what led you to choose 0x30 and 0x31 for the two new values? It does seem that keeping them uniform across architectures is a reasonable thing to do, but as far as I can tell the values 9 and 10 are unused on all architectures, and have the added merit of not falling in the parisc reserved range. Do we still have a chance to change this? - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/