[Pvfs2-developers] patch: alternate AIO implementation

[Phil Carns]

Pete Wyckoff wrote:
> pcarns at wastedcycles.org wrote on Fri, 01 Sep 2006 18:50 +0200:
> 
>>Anyway... there are a couple of options.  I would be happy to implement 
>>any of these:
>>
>>- modify configure.in to define _GNU_SOURCE on linux systems.  This is 
>>very clean.  The only minor downside is that it might allow developers 
>>to accidentally commit code that isn't portable that would have caused a 
>>compile error before.
>>
>>- change pread/pwrite in dbpf-bstream.c to explicitly be 
>>pread64/pwrite64.  The downside is that without _GNU_SOURCE defined we 
>>still have to give our own prototypes for pread64/pwrite64.
>>
>>- define _GNU_SOURCE only in dbpf-bstream.c.  This might be the least 
>>intrusive option.
> 
> 
> Actually my header files seem to protect pread and friends under
> _USE_UNIX98 (on glibc-2.3.2, 2.3.6, and glibc-2.4 is all I checked).
> You can get that by defining a less pervasive set of features than
> _GNU_SOURCE, which basically turns on everything.  Like
> _XOPEN_SOURCE = 500 should be enough.
> 
> But, regardless of which defines you prefer, I agree with Murali and
> would like to minimize the effect by constraining the define to only
> the single source file.  I remember being shocked in the past to
> find that behavior changed when using _GNU_SOURCE, beyond just
> having extra features available.  And your argument about
> portability is compelling.

On gentoo the man page actually lists _XOPEN_SOURCE 500 as the magic 
#define to add when using pread/pwrite, so that was the route that I 
tried first.  This breaks the pvfs2 build, though- apparently that flag 
also turns off some features that we already use in addition to adding 
new ones.  It may work when limited to specific source files, though.

I'll figure out which of these flags works best when applied as Murali 
suggested and come back with a patch.

-Phil