[Box Backup] PATCH: Partial Solaris port

[Ben Summers]

On 28 Nov 2004, at 16:57, Martin Ebourne wrote:

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

OK. The reason the BSD one requires an extra zero is that it's passing 
a 64 bit parameter, which requires two 32 bit parameters. It might be 
argued that if you're going to support files larger than 4Gb, then a 64 
bit parameter is not entirely unreasonable.

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

The other alternative is to use #defines to change the calls to other 
functions in debug builds, but then it means you have different code in 
release and debug modes.

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

It's been a long time, but sounds vaguely familiar.

>  But it's been a few years too! Is this country
> full of ex-Acorners?

Only the good programmers. :-)

>  Still that's way more cycles than a basic read.

Yes, a lot more. Which is why you'd probably use two more to test for 
word-alignness and do a normal load otherwise.

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

Most of the values will be word aligned, so an if statement to check 
for alignment will help most things.

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

For a system which claims to be efficient on bandwidth, I'm not 
convinced adding padding would be a good plan.

Ben