From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] p9p vbackup fs type endiannes
From: "Russ Cox" <rsc@swtch.com>
Date: Thu, 22 Nov 2007 10:42:40 -0500
In-Reply-To: <562BCA89-2B62-4C7A-A570-69E833A7FE32@utopian.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20071122154230.3E4A01E8C22@holo.morphisms.net>
Cc: josh@utopian.net
Topicbox-Message-UUID: 084b7dda-ead3-11e9-9d60-3106f5b1d025

> I'm trying to use p9p's vbackup(8) on a linux powerpc system.
> 
> 	# vbackup -m /boot /dev/hda3
> 	vbackup: ffsopen: bad magic 0x53ef wanted 0xef53
> 
> Linux statfs(2) says 0xef53 is a linux ext2 partition type. There
> is an ext3 partition at /dev/hda3, so vbackup (its call to fsysopen())
> is expecting the right fs type, but seems to be getting the endian
> obverse of that value.
> 
> (The kernel is debian's stock 2.6.18-5-powerpc. P9p is dated 11/08
> from http://swtch.com/plan9port/.)
> 
> Anyone else attempting to doubly edify linux in this fashion
> and seeing likewise?

I have never tried to run the ext2 reading code on a
little-endian machine.  I don't know what changes
and what doesn't.  I would have expected that everything
was in native byte order, so that the "load disk contents
into memory and interpret" strategy would have worked
just fine.  It's possible that the superblock magic code
is really two bytes and not a short, and that if you change
SUPERMAGIC in src/libdiskfs/ext2.h then everything else
will just work.  But it's also possible that you'll have to 
fiddle with other fields.  

Please let me know what you find out.

Thanks.
Russ