Re: negative seek offsets in VFS

[Andi Kleen <ak@muc.de>]

On Wed, May 25, 2005 at 05:56:26PM -0700, Bryan Henderson wrote:
> >My x86-64 users are complaining again that they cannot reach kernel
> >text addresses in /dev/kmem. The reason is that they are negative and
> >the the VFS read and seek code just EINVALs them.
> 
> Come now -- the kernel addresses are not negative, and neither is any file 
> offset.

x86-64 addresses are negative.

> 
> You apparently mean that when you coerce a kernel address which exceeds 
> the range of a file offset type into a file offset type, it comes out 
> negative.

No I meant what I wrote.

> So I guess the real question is why is the loff_t type signed, thereby 
> making it incapable of representing sufficiently large offsets?  The 
> answer is that there are POSIX interfaces that overload a single data 
> structure as both a file offset or size and a status code.  If a loff_t 
> value is positive, it is a file offset, but if it's negative, it's a 
> status code.  Consider lseek -- if you allowed a negative offset and just 
> declared that it stands for the large positive offset you'd get if you 
> coerced it to an unsigned 64 bit integer, then how would you tell a 
> success from a failure in the return code?

The same as any other Linux kernel interfaces do it. The range from -4096 to -1
is reserved for error codes, the rest is free to use.
This is what glibc uses too. It has nothing to do with POSIX.

-Andi