Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 11 Feb 2003 08:20:10 +0100 (CET)
From: Sascha Schumann <sascha@schumann.cx>
To: Justin Erenkrantz <justin@erenkrantz.com>
Cc: "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <madhusudan_mathihalli@hp.com>,
	"'dev@apr.apache.org'" <dev@apr.apache.org>
Subject: RE: [PATCH] Support for opening large files
In-Reply-To: <2147483647.1044917834@[10.0.1.39]>
Message-ID: <Pine.LNX.4.53.0302110758440.1828@eco.foo>
References: <A5374D237E78D41195810090279CC91A08EC7877@xcup04.cup.hp.co m>
 <2147483647.1044915066@[10.0.1.39]>
 <Pine.LNX.4.53.0302110715360.1828@eco.foo>
 <2147483647.1044917834@[10.0.1.39]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> My previous thought was to do a platform-specific disabling of large
> files on Linux (perhaps enabling it where there is a good version of
> glibc).  But, no one ever responded to that idea.  I think it makes
> the most sense, but I don't know.

    It's actually quite simple from my POV and you even get
    binary compatibility for free:

    The implementation checks for the availibility of sendfile
    and sendfile64 at run-time by using

        void *p = dlsym(NULL, "symbolname");

    This will get you a valid function pointer or NULL.  We store
    the retrieved pointers and use them in the abstraction.

    Now, if sendfile64 is available, everything is fine.

    Otherwise, we can use sendfile for sending files until we
    reach an offset of LONG_MAX (this is true for 32 and 64 bit
    systems).  When this situation occurs, a fallback method
    kicks in (I suppose that read/write support is already
    implemented).

    Such a binary should be built on a system with the glibc-2.3
    headers of course.  We could bundle the new header and use it
    instead, if we detect an older system.

    Let me know what you think.

    - Sascha