From owner-svn-src-head@FreeBSD.ORG Sat Mar 13 19:25:00 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE4C106564A; Sat, 13 Mar 2010 19:25:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1068FC18; Sat, 13 Mar 2010 19:25:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2DJJOW5085827; Sat, 13 Mar 2010 12:19:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 13 Mar 2010 12:19:32 -0700 (MST) Message-Id: <20100313.121932.997044077387131740.imp@bsdimp.com> To: ed@80386.nl From: "M. Warner Losh" In-Reply-To: <20100313170725.GW8200@hoeg.nl> References: <20100313090844.GV8200@hoeg.nl> <20100313.090709.407454645627448944.imp@bsdimp.com> <20100313170725.GW8200@hoeg.nl> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: unixmania@gmail.com, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, nwhitehorn@FreeBSD.org Subject: Re: svn commit: r205014 - in head: . sys/amd64/amd64 sys/amd64/conf sys/amd64/include sys/amd64/linux32 sys/compat/freebsd32 sys/compat/ia32 sys/conf sys/fs/procfs sys/ia64/conf sys/ia64/ia64 sys/ia64/... X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 19:25:00 -0000 In message: <20100313170725.GW8200@hoeg.nl> Ed Schouten writes: : * M. Warner Losh wrote: : > that sounds like a good idea. But it isn't as simple as changing all : > the COMPAT_FREEBSDX in the .c code. There's also hooks in the syscall : > glue generation that would be affected. : : Hmmm... Indeed. : : I thought a bit more about this and I realized it would be better if we : wouldn't use a FreeBSD major number for this, but the actual : __FreeBSD_version. Hmmm, that might be harder. The problem is that when I want to run a program from FreeBSD 3.0, I may need an interface that was in 3.0, but was removed prior to 5.0 shipping. This means the kernel needs the COMPAT_FREEBSD4 option right now to work. So things are kind of confusing. Under your plan, which __FreeBSD_version would we use here? The COMPAT_FREEBSD_BACK_TO=3 would be the right setting here. This may pick up a little extra junk, but would be clear to the user what they are configuring. Comments? Warner