From owner-freebsd-arch@FreeBSD.ORG Mon Jun 14 18:01:49 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0258D106566C; Mon, 14 Jun 2010 18:01:49 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id CAEAF8FC24; Mon, 14 Jun 2010 18:01:48 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0L4000904KMYE700@smtpauth3.wiscmail.wisc.edu>; Mon, 14 Jun 2010 12:01:46 -0500 (CDT) Received: from anacreon.physics.wisc.edu (anacreon.physics.wisc.edu [128.104.160.176]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L40006B2KMUWS30@smtpauth3.wiscmail.wisc.edu>; Mon, 14 Jun 2010 12:01:42 -0500 (CDT) Date: Mon, 14 Jun 2010 12:01:41 -0500 From: Nathan Whitehorn In-reply-to: To: mdf@FreeBSD.org Message-id: <20100614120141.3876ec6d@anacreon.physics.wisc.edu> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; powerpc64-portbld-freebsd9.0) X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-12, Version=5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.6.14.165113, SenderIP=128.104.160.176 References: Cc: freebsd-arch@freebsd.org Subject: Re: arch-specific directories X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 18:01:49 -0000 On Mon, 14 Jun 2010 08:26:45 -0700 mdf@FreeBSD.org wrote: > This is as much as request for information as a suggestion. > > I am wondering of the current layout of sys/ make sense given > that in several cases the only difference between two "arch" is the > bitness, e.g. powerpc and powerpc64. The 64-bit version supports a > few new instructions, but in many cases is the same. The same issue > exists with i386/amd64 but because both have been supported for a long > time the have full arch separation. However, there has been some > movement of files that are common between i386 and amd64 into a common > x86 directory. > > So what I'm wondering is it it makes more sense to have files broken > up more like: > > sys/ for common file between bitness > sys//32 > sys//64 for files that are specific to the bitness > > This would presumably serve at least powerpc and i386/amd64 well, and > though I don't know for sure I assume at the moment that it works for > sun/sparc as well. PowerPC actually does something very similar to what you suggest -- the sys/powerpc64 directory is a stub (containing only symlinks) that will go away when the projects/ppc64 branch is merged. Almost everything to do with the 32/64-bit difference is keyed off of #ifdef __powerpc64__, which has several nice side effects, like allowing cc -m32 to work, as well as simplifying maintenance by using a common code base. Having written support for a "new" platform this way, I can attest that shared code like you suggest is a very good idea. > So... is this reasonable? Or does the existence of ia64 throw a > monkey wrench into this layout? Is it not worth the shuffle (though > I'd argue that, if we're moving some files to x86 and creating a new > powerpc64 that it's better to consider now than later). > > I realize there was a discussion earlier along similar lines (the > bi-yearly architecture source tree layout discussion) but I don't > think it was specifically considering the 32/64 bit differences, which > seem to be more common now. The larger scope of this is the work being done by M. Warner Losh (the "TARGET_BIG_ENDIAN must die" branch), which he is currently merging. This defines a new thing, MACHINE_CPUARCH, that would be 'powerpc', with MACHINE_ARCH values of 'powerpc' and 'powerpc64', and is what will allow sys/powerpc64 to disappear. I'm sure he can describe it in more detail. -Nathan