From owner-freebsd-arch@FreeBSD.ORG Thu Jun 17 21:29:05 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 2756E1065703; Thu, 17 Jun 2010 21:29:05 +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 CEE4B8FC15; Thu, 17 Jun 2010 21:29:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5HLMrkE074718; Thu, 17 Jun 2010 15:22:53 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 17 Jun 2010 15:22:56 -0600 (MDT) Message-Id: <20100617.152256.634347869525781000.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <201006141251.45896.jhb@freebsd.org> References: <201006141251.45896.jhb@freebsd.org> 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: mdf@FreeBSD.org, 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: Thu, 17 Jun 2010 21:29:05 -0000 In message: <201006141251.45896.jhb@freebsd.org> John Baldwin writes: : On Monday 14 June 2010 11:26:45 am 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. : > : > 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. : : I think for archs that share a lot in common between 32-bit and 64-bit : varieties using shared sources of some sort (e.g. sys/x86) should be : encouraged. This is probably more true (and feasible) for more recently added : architectures such as powerpc, arm, and mips. Alpha and ia64 would not have : fit into this category. Since we do not support 32-bit sparc, sparc64 doesn't : really fit into it either. Having a common directory is a good thing. : However, I think that some of our build infrastructure assumes that that the : current MACHINE/TARGET is in the path, so e.g. make buildkernel uses : sys/$TARGET/conf to find the kernel config file to build, so we may be stuck : with some of the layout differences at the top-level. I suspect the arm, : powerpc, and mips target names are already embedded at this point, but I would : not mind an organization where common code lived in sys/mips and 32-bit and : 64-bit bits lived in sys/mips32 and sys/mips64. (That would work with the : existing kernel config path assumptions, but require changing 'arm' -> : 'arm32', etc. for MACHINE/TARGET). I'm sure Warner has some ideas on this : topic as well. MACHINE=arm, but MACHINE_ARCH=arm or armeb. MACHINE_CPUARCH=arm. MACHINE specifies the kernel sources. MACHINE_ARCH is the arch/endian specification. MACHINE_CPUARCH is the cpu family. For mips, all the source is shared between 32-bit and 64-bit variants for both userland and kernel. Warner