[Box Backup] PATCH: Partial Solaris port

Ben Summers boxbackup@fluffy.co.uk
Tue, 23 Nov 2004 12:29:54 +0000

On 23 Nov 2004, at 11:40, Martin Ebourne wrote:

> Here's most of a Solaris port. Currently it all compiles but does not 
> pass
> the testsuite. I don't have time to look at this just at the moment so
> posting here for others to play with. Diff is against 0.08PLUS2.

I would appreciate feedback on this patch. I think I'm going to do a 
maintenance release as soon as the 2Gb thing is sorted out (which 
currently appears to be an odd behaviour of zlib, which I'm trying to 
track down with Nick) and it would be nice to include it. But it's 
another of those platforms I can't test.

> Things to note:

1 -- 7 all seem reasonable.

> 8. Took me ages to find why lseek was behaving bizarrely. Eventually I
> discovered lseek in intercept.cpp, but only after resorting to machine
> level debugging. Not sure why it was assumed that the 'default' 
> platform
> has the bizarre mapping to the system call. That must be a BSD thing. 
> :)

Actually I think this is a random side effect of library linkage. I've 
given up trying to support it when Linux LFS is running, so there's now 
a switch to turn off that testing if it's nasty on that platform. I 
suggest you add it for your platform.

But can anyone suggest a better way of testing what happens when you 
get errors from the filesystem?

> 9. SPARC does not allow int32 access on non-aligned boundaries. This
> breaks the protocol handling code of course. I've put a work around in
> for now, but really the protocol should be changed to be word aligned
> because otherwise there'll be a significant hit on most RISC 
> processors.

I remember from my ARM assembly days that you can do non-aligned reads 
in a couple of reads and an AND of shifted values. But I think these 
processors will just have to take the hit.

> 10. For (9) I had to add processor detection to the build system. One
> step closer towards autoconf...


> I've also attached the log files from the test that's failing on the
> off-chance Ben knows exactly what the fix is, like last time.
Nothing really springs to mind, although you could try increasing the 
delay just before the failure in case it's being really slow or 
something. Some of these tests are quite timing dependent. Writing them 
is painful.

I've had a look through the diffs, and would be happy to commit it all 
after a few success reports. Thanks for your hard work.