On Mon, Jul 16, 2001 at 06:27:48PM +1000, Nathan Scott wrote:
>
> On Jul 16, 10:21am, ThH wrote:
> > Subject: Re: xfsdump on alpha
> > ...
> > You say it's an incompatibility of the dump data structure and the alpha
> > system headers. What's with other 64bit systems like IA64, sparc64 or
> > mips64, they might have the same problem. I'm right?
>
> Yes, you're right - they almost certainly will have this
> problem too.
>
On IRIX though, we currently only build xfsdump/xfsrestore N32 and
not 64 bit. (Also on IRIX, time_t is defined as 32 bit for
mips 32 and 64.)
> >
> > I will use xfsdump. Can you tell me what I've to do, too solve this
> > problem?
> >
>
> You'll need to audit all uses of time_t in xfsdump tools
> - if any of these are in data structures which are to be
> written on the tape, then you will need to make up a new
> type (eg. time32_t) and then change the code to use that
> instead of time_t, ensuring all the places where a 8byte
> time_t are needed (eg. libc entry points, syscalls, etc)
> still use that, but a conversion to a 32bit version must
> be done subsequently before the data structure is written
> anywhere permanently.
>
> At the same time, you'll need to ensure that the code for
> 32 bit platforms is effectively unchanged - eg. time32_t
> could equate to time_t on those platforms, thru use of cpp
> macros, etc.
>
> hope this helps.
There, of course, _could_ be other types with a similar fate
to time_t. You need to ensure that the dump format (on tape
or on file) remains unchanged to the 32 bit version
(if you want compatibility).
--Tim
|