From owner-svn-src-all@FreeBSD.ORG Tue Jun 23 23:39:23 2009 Return-Path: Delivered-To: svn-src-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54A9C1065673; Tue, 23 Jun 2009 23:39:23 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id E77478FC15; Tue, 23 Jun 2009 23:39:22 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n5NNjnWa006264; Tue, 23 Jun 2009 19:45:49 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n5NNjnPT006263; Tue, 23 Jun 2009 19:45:49 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 23 Jun 2009 19:45:49 -0400 From: David Schultz To: Kostik Belousov Message-ID: <20090623234549.GA6076@zim.MIT.EDU> Mail-Followup-To: Kostik Belousov , Ed Schouten , src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG References: <200906201639.n5KGdPhO081114@svn.freebsd.org> <20090620174158.GG2884@deviant.kiev.zoral.com.ua> <20090623221248.GA5445@zim.MIT.EDU> <20090623221053.GT2884@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090623221053.GT2884@deviant.kiev.zoral.com.ua> Cc: svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG, Ed Schouten Subject: Re: svn commit: r194538 - head/sys/sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 23:39:23 -0000 On Wed, Jun 24, 2009, Kostik Belousov wrote: > On Tue, Jun 23, 2009 at 06:12:48PM -0400, David Schultz wrote: > > On Sat, Jun 20, 2009, Kostik Belousov wrote: > > > On Sat, Jun 20, 2009 at 04:39:25PM +0000, Ed Schouten wrote: > > > > Author: ed > > > > Date: Sat Jun 20 16:39:25 2009 > > > > New Revision: 194538 > > > > URL: http://svn.freebsd.org/changeset/base/194538 > > > > > > > > Log: > > > > Add placeholder to prevent reuse of privilege 254. > > > > > > > > Requested by: rwatson > > > > > > > > Modified: > > > > head/sys/sys/priv.h > > > > > > > > Modified: head/sys/sys/priv.h > > > > ============================================================================== > > > > --- head/sys/sys/priv.h Sat Jun 20 16:37:24 2009 (r194537) > > > > +++ head/sys/sys/priv.h Sat Jun 20 16:39:25 2009 (r194538) > > > > @@ -211,6 +211,7 @@ > > > > #define PRIV_TTY_DRAINWAIT 251 /* Set tty drain wait time. */ > > > > #define PRIV_TTY_DTRWAIT 252 /* Set DTR wait on tty. */ > > > > #define PRIV_TTY_EXCLUSIVE 253 /* Override tty exclusive flag. */ > > > > +#define _PRIV_TTY_PRISON 254 /* Removed. */ > > > > #define PRIV_TTY_STI 255 /* Simulate input on another tty. */ > > > > #define PRIV_TTY_SETA 256 /* Set tty termios structure. */ > > > > > > > Names starting with two underscores or underscore and upper-case letter > > > are reserved to the C language implementation. We should not use it > > > in the code. > > > > Applications are not supposed to use such symbols, but we use them > > pervasively in system headers specifically to avoid conflicting > > with symbols an application might define. (Effectively, we > > consider system headers to be part of the language implementation.) > > My interpretation is that we use freestanding environment for the kernel, > and appropriate requirements shall be fullfilled by kernel code. If that's the case, then how do you propose we cope with the boilerplate preface to virtually every header file, i.e., like the following? #ifndef _SYS_PRIV_H_ #define _SYS_PRIV_H_ The intent of the restrictions on names with underscores is to provide a namespace for implementors of libraries and header files that will not conflict with conforming applications. (In this context, I guess it makes more sense to talk about third-party modules instead of applications.) Of course the compiler may also define symbols in this namespace, but that's a much more manageable problem, notwithstanding the fact that compiler authors are generally careful to use more specific prefixes such as `__STDC' and `__GNUC'.