[Box Backup] PATCH: Partial Solaris port

[Martin Ebourne]

On Tue, 2004-11-23 at 12:29, Ben Summers wrote:
> On 23 Nov 2004, at 11:40, Martin Ebourne wrote:
> > 8. Took me ages to find why lseek was behaving bizarrely. Eventually I
> 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.

It doesn't need to be disabled - I got it working, just had to fix the
parameters to the syscall to be sensible, like the Linux ones, and for
once, not like the BSD ones. ;)

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

I've not come up with anything so far...

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

Something like:
	AND	r1, r0, #3
	XOR	r0, r0, r1
	MOV	r1, r1, LSL #3
	LDMIA	r0, {r2, r3}
	MOV	r2, r2, LSR r1
	RSB 	r1, r1, #32
	ORR	r2, r2, r3, LSL r1

off the top of my head. But it's been a few years too! Is this country
full of ex-Acorners? Still that's way more cycles than a basic read.

Thing is, I don't think gcc does this. It certainly doesn't for sparc -
all you get is a bus error when it runs. Not too helpful. The
workarounds in C are a fair bit more involved (not to mention be/le),
which is why I substituted memcpy. Not efficient though!

I think changing the protocol so that values are always aligned to their
size (4 bytes on 4 byte boundary, 2 bytes on 2, 8 on 8, etc) would be
well worthwhile, and would solve all this. It would be an incompatible
change between client & server, but perhaps better to do this now before
box hits the big time.

Cheers,

Martin.