From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 04:50:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A06771065670; Mon, 7 Nov 2011 04:50:43 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id ACC218FC08; Mon, 7 Nov 2011 04:50:42 +0000 (UTC) Received: by wwp14 with SMTP id 14so6156173wwp.31 for ; Sun, 06 Nov 2011 20:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NLFLH8PGWhfmVman1gua4f/f5+ttwYwsvkY+PLnib4U=; b=rMouRy42A7a1sbG9gt7f8MESymRTdOGV+TbhN+6Bhyaje9fqC7Usddas7kXbFn7F+7 gZMTytoJN43tMFxdNyMOYVxLPnsRrvUR1o5Uc4+75v6naXcb7vRYO0evQP0hNX7bwNSj xinQLPDfspwYeRHftxQnJDFZ2LvDKYUexZEAA= MIME-Version: 1.0 Received: by 10.180.3.33 with SMTP id 1mr6823680wiz.54.1320641441619; Sun, 06 Nov 2011 20:50:41 -0800 (PST) Received: by 10.180.80.195 with HTTP; Sun, 6 Nov 2011 20:50:41 -0800 (PST) In-Reply-To: <20111106164204.GY50300@deviant.kiev.zoral.com.ua> References: <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <20111106164204.GY50300@deviant.kiev.zoral.com.ua> Date: Sun, 6 Nov 2011 23:50:41 -0500 Message-ID: From: Arnaud Lacombe To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 04:50:43 -0000 Hi, On Sun, Nov 6, 2011 at 11:42 AM, Kostik Belousov wrot= e: > On Sun, Nov 06, 2011 at 07:22:51AM -0800, mdf@freebsd.org wrote: >> On Sun, Nov 6, 2011 at 4:43 AM, Kostik Belousov wr= ote: >> > Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has >> > a lot of violations in regard of the namespaces, IMO. The __* namespac= e >> > is reserved for the language implementation, so our freestanding progr= am >> > (kernel) ignores the requirements of the C standard with the names lik= e >> > __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes >> > it not unreasonable for other developers to introduce reserved names. >> > So I decided to use the suffixes. vm_map.h locking is free of these >> > violations. >> >> I'm pretty sure that when the C standard says, "the implementation", >> they're referring to the compiler and OS it runs on. =A0Which makes the >> FreeBSD kernel part of "the implementation", which is precisely why so >> many headers have defines that start with __ and then, if certain >> posix defines are set, also uses non-__ versions of the name. > > For libc providing parts, required by standard, you are right. > But our kernel is a freestanding program using a compiler, so in-kernel > uses of the reserved namespace is a violation. > So you prefer to introduce a new notation which will confuses everybody for the sake of following an interpretation of the standard[0] ? Btw, which point of the standard are you quoting ? Section "7.1.3 Reserved identifiers" of ISO/IEC 9899 ? Thanks, - Arnaud ps: my vote is for a deep-sky-blue bikeshed. [0]: I'd be tempted to interpret "the implementation" as the non-visible part of an API, ie vm_page_lock() is public and rely on __vm_page_lock() for its implementation. As such, I would not consider "the kernel" as a single whole unit, but as a sum of public API and implementation.