apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: RFC: Unix LFS support for 1.0
Date Mon, 22 Mar 2004 14:41:41 GMT
On Mon, Mar 22, 2004 at 09:16:02AM -0500, Jeff Trawick wrote:
> Joe Orton wrote:
> >- AIX and Solaris have variants for their sendfile interfaces which take
> >an off64_t in the appropriate place; need to hook these up and check
> >HP-UX too (### help welcome! :)
> AIX: looks to me that the file offset and bytes-to-send fields were always 
> 64-bit, and there is just one send_file() and just one sendfile-parms 
> structure

Excellent! Thanks.

> >- what to do about old Linux 2.2's which have no sendfile64(): disable
> >sendfile support, or disable LFS support? both change the ABI
> from an ABI standpoint (given that there is no 1.0 ABI yet), it seems safer 
> to turn off sendfile support and turn on lfs support when sendfile and lfs 
> conflict...   if an app was built without APR_HAS_SENDFILE and the user 
> upgraded the OS and rebuilt apr such that apr could support both sendfile 
> and lfs, the old app binary would still work fine with the new apr, since 
> adding the sendfile capability would not change the interface to existing 
> capabilities

I looked through the various dicussions about this previously...

How about this: for the Linux case APR_HAS_LARGE_FILES &&
!defined(HAVE_SENDFILE64) && sizeof(off_t) == 4, just define
apr_socket_sendfile() as a wrapper which returns EINVAL if passed
(*offset + *len) > INT_MAX, and otherwise handles thunking between the
off64_t and off_t correctly for <2gb files?

That means no regression since 0.9.x on such platforms (since 0.9.x
can't do anything with >2gb files let alone sendfile() them); and in
general everything else works the same or better, just with yet another
obscure edge case where apr_socket_sendfile() fails (and more ammunition
to get EnableSendfile be Off by default in httpd :).

> whatever the decision is, a --disable-lfs is useful because the decision 
> will
> be wrong for somebody and there may be specific platform problems that need
> an easy work-around

OK, will add, thanks.


View raw message