From owner-freebsd-sparc64@FreeBSD.ORG Sat Feb 11 07:26:57 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AA4D16A420 for ; Sat, 11 Feb 2006 07:26:57 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB76543D49 for ; Sat, 11 Feb 2006 07:26:56 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k1B7Qtvj012920; Sat, 11 Feb 2006 00:26:55 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43ED91BF.3070803@samsco.org> Date: Sat, 11 Feb 2006 00:26:55 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Tanis References: <43EA72B9.5070307@gmail.com> <20060209203330.GA11506@xor.obsecurity.org> <65dcde740602100951k17bf8330o15e1b78bd2ee55be@mail.gmail.com> <20060210201417.GC67059@xor.obsecurity.org> <65dcde740602102152r2fa8b788r1d035222a66ec958@mail.gmail.com> In-Reply-To: <65dcde740602102152r2fa8b788r1d035222a66ec958@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-sparc64@freebsd.org, Kris Kennaway Subject: Re: moving disks between archs X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2006 07:26:57 -0000 James Tanis wrote: > On 2/10/06, Kris Kennaway wrote: > >>On Fri, Feb 10, 2006 at 12:51:18PM -0500, James Tanis wrote: >> >>>Tar will work, but not a drive formatted on an i386 with a tar file on >>>it. >> >>Not if you store the tar file in a UFS filesystem on the drive, but I >>suggested writing it to the raw disk where it is just a stream of bits >>and therefore endian-neutral. >> > > > That would imply that endianness is a function of the OS/filesystem > rather than the architecture, which is wrong. If you don't take my > word for it, a quick google will find you, > (http://developers.sun.com/solaris/articles/support_for_x86.html).. > "File systems are neutral to endianness in general, and swapping files > between Solaris SPARC and x86 is not an issue. But applications > storing raw data that can be shared between platforms would be an > issue. For example, if an application on the Solaris SPARC platform > writes the data structures in a raw format to the files, then the data > stored in these files would be endian-dependent." > > You are quoting a feature of Solaris UFS, not a fundamental invariant of all filesystems. Filesystems do store 16, 32, and 64 bit metadata quantities, and it's up to the reader/writer implementation on how to interpret them. You either need to decide that the on-disk metadata will always be either big or little endian, and leave it up to the implementation to do the appropriate byte swapping (similar to the network protocols that are big-endian by definition), or you have to provide some way for the filesystem to indicate which endian format it is in and let the OS adapt accordingly. I don't know about Solaris, but I do know that NetBSD implements a form of the latter. FreeBSD does not; UFS metadata is written in the endian format of the host, and no mechanisms for provided to allow detection and conversion of this. It would be a nice feature to adopt from NetBSD at some point. Scott