On Fri, 7 Feb 1997, David Brownlee wrote:

> 
> On Fri, 7 Feb 1997, Andrew Cagney wrote:
> 
> > In the longer term, however, I suggest that it would be a good strategy
> > to steer the FS tools in a direction that allowed them to be built and
> > used on foreign hosts.
> > 
> 	Most certainly - 'disklabel' currently has code that installs
> 	bootblocks on some (i396) architectures. I think this has been
> 	described as 'just plain wrong'.
> 
> 	The first stage that needs to be done is splitting out the
> 	disklabel handling code from the ports - so I can for example
> 	mount a SunOS disk on a NetBSD/i386 machine. Before that
> 	happens we need to cope with big/little endian ffs on a given
> 	machine.

I've been thinking about this probelem. It shouldn't be TOO hard, though
tedious. My thought was to add partition types of BE_FFS and LE_FFS (sp?),
and to leave FFS as-is. Also, teach disklabel about different disklabel
types, like big-E NetBSD, little-E NetBSD, sun, DOS, cd9660, amiga, atari,
etc..

The idea is to have stub routines which can read (and write) each
partition scheme. The stubs would also use BE_FFS & LE_FFS if the
disklabel's made dynamically (from the other OS's scheme), or if the
disklabel nativly was for a different byte order (like you take a Big-E
sun disklabel (w/ FFS's in it) and hook it to an i386).

The thought for BE_FFS and LE_FFS is to pepper the ufs code w/ wrappere
where ever on-disk entities are touched. To make the native-endian fs,
these wrappers are null (#define wrapper(x)  (x)).

> 	Actually, from my viewpoint just being about to mount a DOS
> 	formatted Jaz disk on my NetBSD/sparc box would be real nice, but
> 	I'm upgrading to current in preparation for poking around at that
> 	:)

The other (cool but essoteric) thing it can do is you could tell disklabel
to look for a certain type of disk label. Zip Tools disks have both DOS
and MacOS partitions on them, and this way we could read them (and
possably write them too!).

Take care,

Bill