You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Joe Orton <jo...@manyfish.co.uk> on 2004/03/22 22:40:44 UTC
[PATCH] LFS support for 1.0, take 2
Updated patch attached, thanks for the feedback so far...
TODO:
* hook up Solaris sendfilev64 if necessary
* test the sendfile thunks work
* adjust ssize_t rc handling for HP-UX sendfile64 case
CHANGES:
* sendfile foo:
- Linux: sendfile64 or thunk
- HP-UX: sendfile64 or thunk
- AIX: Just Works (adjusted casts)
* add -D_LARGEFILE64_SOURCE automagically
* drop readdir64_r()/readdir64() support as it's not a necessary part
of this change, and the Solaris readdir64_r() is weird.
* support configure --disable-lfs and simplified checks
* unbreak Netware
* unbreak platforms with a 64-bit native off_t
Re: [PATCH] LFS support for 1.0, take 2
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Wed, Mar 24, 2004 at 10:11:29AM -0500, Jeff Trawick wrote:
> Note that these lines now generate a gcc 3.2 warning for casting from a
> pointer to an integer of a different size (32 bits into 64 bits). But the
> Solaris API is such that you have to stuff a pointer to an integer.
>
> + sfv[curvec].sfv_off = (apr_off_t)hdtr->trailers[i].iov_base;
>
> I don't know of an elegant fix to silence the warning.
Oh nasty! sendfilev64 does actually expect a 32-bit pointer in that
field, though? Not sure what's needed other than the explicit cast...
(apr_off_t)(unsigned int) ifdef'd for the 32-vs-64 case or something?
joe
Re: [PATCH] LFS support for 1.0, take 2
Posted by Jeff Trawick <tr...@attglobal.net>.
Joe Orton wrote:
> Thanks, added that too with the configure check for sendfilev64. Take 3
> is about ready to be committed, I think.
I can't imagine any showstoppers at this point. Committing real soon seems to
be the right thing to do.
> TODO:
>
> * test the sendfile thunks work
> * adjust ssize_t rc handling for HP-UX sendfile64 case
>
> CHANGES:
>
> * have apr_file_mktemp use mkstemp64 where available
> * use CuNotImpl rather than fail testlfs when the truncate gets E2BIG
> (usually due to rlimit or fs limits)
> * sendfile foo:
> - Solaris: sendfilev64 + adjusted casts
Note that these lines now generate a gcc 3.2 warning for casting from a pointer
to an integer of a different size (32 bits into 64 bits). But the Solaris API
is such that you have to stuff a pointer to an integer.
+ sfv[curvec].sfv_off = (apr_off_t)hdtr->trailers[i].iov_base;
I don't know of an elegant fix to silence the warning.
Re: [PATCH] LFS support for 1.0, take 2
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Mon, Mar 22, 2004 at 05:14:43PM -0500, Jeff Trawick wrote:
> Joe Orton wrote:
> >Updated patch attached, thanks for the feedback so far...
> >
> >TODO:
> >
> >* hook up Solaris sendfilev64 if necessary
>
> looks necessary... dunno if there was a Solaris with sendfilev but no
> sendfilev64 such that we'd have to thunk... for now I have this just for
> playing in the Solaris sendfilev() interface:
>
> #if APR_HAS_LARGE_FILES /* && defined(HAVE_SENDFILEV64) */
> #define sendfilevec_t sendfilevec64_t
> #define sendfilev sendfilev64
> #endif
Thanks, added that too with the configure check for sendfilev64. Take 3
is about ready to be committed, I think.
TODO:
* test the sendfile thunks work
* adjust ssize_t rc handling for HP-UX sendfile64 case
CHANGES:
* have apr_file_mktemp use mkstemp64 where available
* use CuNotImpl rather than fail testlfs when the truncate gets E2BIG
(usually due to rlimit or fs limits)
* sendfile foo:
- Solaris: sendfilev64 + adjusted casts
- Linux: sendfile64 or thunk
- HP-UX: sendfile64 or thunk
- AIX: Just Works
* add -D_LARGEFILE64_SOURCE automagically
* drop readdir64_r()/readdir64() support as it's not a necessary part
of this change, and the Solaris readdir64_r() is weird.
* support configure --disable-lfs and simplified checks
* unbreak Netware
* unbreak platforms with 64-bit native off_t
Re: [PATCH] LFS support for 1.0, take 2
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick wrote:
> Joe Orton wrote:
>
>> Updated patch attached, thanks for the feedback so far...
>>
>> TODO:
>>
>> * hook up Solaris sendfilev64 if necessary
>
>
> looks necessary... dunno if there was a Solaris with sendfilev but no
> sendfilev64 such that we'd have to thunk... for now I have this just for
> playing in the Solaris sendfilev() interface:
>
> #if APR_HAS_LARGE_FILES /* && defined(HAVE_SENDFILEV64) */
> #define sendfilevec_t sendfilevec64_t
> #define sendfilev sendfilev64
> #endif
>
> definite issue with apr_file_info_get on Solaris
no, ignore that last comment ;) I must have had some stray bits from a
previous build somewhere
Re: [PATCH] LFS support for 1.0, take 2
Posted by Jeff Trawick <tr...@attglobal.net>.
Joe Orton wrote:
> Updated patch attached, thanks for the feedback so far...
>
> TODO:
>
> * hook up Solaris sendfilev64 if necessary
looks necessary... dunno if there was a Solaris with sendfilev but no
sendfilev64 such that we'd have to thunk... for now I have this just for
playing in the Solaris sendfilev() interface:
#if APR_HAS_LARGE_FILES /* && defined(HAVE_SENDFILEV64) */
#define sendfilevec_t sendfilevec64_t
#define sendfilev sendfilev64
#endif
definite issue with apr_file_info_get on Solaris, which breaks (or crashes) a
few testall testcases... hope to look further this evening, as well as try the
patch on some different boxes... here's a sample:
$ ./testall -v testfileinfo
Partial APR Tests:
File Info: ..FFF
5 tests run: 2 passed, 3 failed, 0 not implemented.
Failed tests in File Info:
1) test_stat_eq_finfo: apr_stat and apr_getfileinfo differ in size
2) test_buffered_write_size: assert failed
3) test_mtime_set: assert failed