Subject: Re: NeXT file systems
To: Marc Boschma <marcb@bms.itg.telecom.com.au>
From: Michael Graff <explorer@flame.org>
List: current-users
Date: 02/09/1996 13:54:09
>Maybe the best way to acheieve this is that a separate file system, based
>(or utilising the source of FFS with #defines) could be the best way.
>
>ie. beffs Big Endian FFS
> lefss Little Endian FFS
Yick. Other than having two seperate in kernel systems, I would write
it more like this:
When the system is mounted, read in the magic number. If it's
the wrong byte ordering, set a ``byte_swap'' flag.
When reading any on-disk structures which are in machine byte
order, swap the order if byte_swap is set.
This could be #ifdef'd out with an ``options UNIVERSIALFFS'' or
something. ;)
Also, fsck and newfs would do the same sort of swapping if asked
nicely to. I could likely do the newfs and kernel portions, given
enough free time. The fsck part kinda scares me ;)
It would make things much easier to use vnd's for testing and such.
I only have access to i386 and pmax -- both seem to have the same byte
ordering. Can someone make a small (2-4 meg max) file system with
big-endian ordering and ftp it to ftp://ftp.flame.org/incoming?
And remember, an empty file system should compress quite well. :)
>Now is it enough to just convert the structures, or are there size problems
>with the structures on different architecures (different pack rules for
>alignment etc.) ?
Disk is disk is disk, isn't it? If the only broblem is byte order, I
would think the on-disk strudtures are well defined and would not
change in size or alignment.
Even 64-bit machines can deal with 32 bits. :)
Class time. Being a graduating senior is so nice. First class @ 2pm,
ends at 3. Gotta love life ;)
--Michael
--
Michael Graff <explorer@flame.org> NetBSD is the way to go!
PGP key on a key-server near you! Netshade the world!