xfs
[Top] [All Lists]

Re: xfsdump on alpha

To: ThH <thh@xxxxxxxxxxxx>
Subject: Re: xfsdump on alpha
From: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 16 Jul 2001 18:27:48 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: ThH <thh@xxxxxxxxxxxx> "Re: xfsdump on alpha" (Jul 16, 10:21am)
References: <995262801.828.0.camel@xxxxxxxxxxxxxx> <10107161617.ZM208491@xxxxxxxxxxxxxxxxxxxxxxxx> <995271702.989.0.camel@xxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
hi,

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.

> 
> 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.

cheers.

-- 
Nathan


<Prev in Thread] Current Thread [Next in Thread>