[OpenAFS-devel] Solaris 10 - 1.4.3rc3 kernel modules build issues

[Jeffrey Hutzelman]

On Friday, March 09, 2007 03:51:32 PM -0600 "Douglas E. Engert" 
<deengert@anl.gov> wrote:

>
>
> Derrick J Brashear wrote:
>> On Fri, 9 Mar 2007, Douglas E. Engert wrote:
>>
>>> It was not clear if this was a name made up by AFS, or a
>>> name that is defined on some OS. If its an AFS made up name than
>>> I agree.
>>
>> The idea was to use the OS' definition, if they defined it. However, the
>> question then is whether OFFSET_MAX(fd) is portable, or whether this is
>> just inherently a non-portable macro and we have to do something ugly.
>>
>
> If I understand the comments in the code in that area, you are trying
> to detect if the af->l_len is the max value for an offset,  or if Java
> may have passed in a 32 bit 0x7ffffffe, as this is what Java thinks is
> the max. And why would java use the -1?

The comment is mostly useless.  Please see the earlier mailing list thread 
in which the author of that patch points out that his original reference to 
0x7ffffffe is in error, and the correct value is in fact 
0x7ffffffffffffffe.  The comments about -1 and 32 bits are merely an 
attempt at explaining why some java implementations erroneously request 
whole-file locks using that offset, but the explanation is irrelevant - the 
important thing is that the bug exists, and this works around it.

> If so, the use of 0x7fffffff in line 547 for non UNIX machines
> is not right as it assumes a 32 bit offset. It really needs to look
> at the max for an offset. The code after the comment about Java and 32
> bit offset -1 does not make sense when using a OFFSET_MAX which is 64
> bits.

Only the code after the comment is new.  The code before it is correct - on 
AFS_LINUX24_ENV, we use OFFSET_MAX; on other platforms we use 0x7fffffff 
always, and, on 64-bit-kernel platforms, _also_ LONG_MAX 
(0x7fffffffffffffff).  This has nothing whatsoever to do with the Java 
issue; it is simply detecting cases where user-land or the OS depicts a 
whole-file lock using the maximum possible offset instead of 0.  It's also 
not new.

-- Jeff