[Libvir] Repository for work-in-progress storage patches

[Daniel P. Berrange]

On Sat, Jan 19, 2008 at 07:58:31PM +0100, Jim Meyering wrote:
> "Daniel P. Berrange" <berrange at redhat.com> wrote:
> > On Sat, Jan 19, 2008 at 07:09:31PM +0100, Jim Meyering wrote:
> >> "Daniel P. Berrange" <berrange at redhat.com> wrote:
> >> ...
> >>
> >> Since you're working on the weekend ;-), here are some
> >> notices I'd begun to accumulate:
> >>
> >>   There are a bunch of new uses of open64, which isn't portable.
> >>   How about using AC_SYS_LARGEFILE in configure.in instead?
> >>   Then you can use "open" everywhere.
> >
> > AFAIK, there are two ways to do large file suport
> >
> >   - Explicit support - size_t, open, etc all remain the same, and
> >     new size64_t, open64, etc are introduced.
> >
> >   - Implicit support - size_t, open, etc are re-defined to be 64-bit
> >     at all times.
> >
> > Both are part of POSIX. With the latter, if any size_t is exposed in your
> > public API, then all applications linking against you must also be compiled
> > with large file suport because this is an ABI sensitive think.  With the
> > former approach all the large file stuff is only visible inside your code
> > so is not leaked to applications using the lib.
> >
> > Since we have size_t in the public API, AFAICT, we have no choice but to
> > use the explicit size64_t, open64() etc.
> 
> large-FILE support does not affect the memory-related size_t
> and ssize_t types, and open64/size64_t are not specified by POSIX.

Opps, it seems Large File Support is actually an X/Open UNIX standard
rather than POSIX.

> Maybe you're thinking of off_t, since that type does change size
> depending on whether large-file support is enabled.  But off_t is
> not used in libvirt at all.

Yes, I was mistaken about size_t - its only the file related types
that change.

So, if we use AC_SYS_LARGEFILE, then all file related APIs - open,
statfs, statvfs, etc, etc become 64-bit across the whole of libvirt
but doesn't leak out into API. So i'm fine with that.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|