[PATCH 05/11] xfsprogs: missing and dummy calls for OS X support

[Jan Tulak]

As I got stuck with some C-related things in the changes for much longer
than I
anticipated, I'm making just this reply now - patches will came once I get
it
working.

On Mon, Aug 17, 2015 at 9:32 PM, Christoph Hellwig <hch at infradead.org>
wrote:
>
> Do you have any idea why MacOS defines a uuid_t, but wants unsigned
> char arguments to uuid_compare?
>

​uuid_t works too. :-)​​



> > +static inline int nftw64(const char *path, int (*fn)(const char *,
> const struct stat *ptr, int flag, struct FTW *), int depth,
> > +         int flags)
> > +{
> > +     return nftw(path, fn, depth, flags);
> > +}

> +#define MREMAP_FIXED 1
> > +#define MREMAP_MAYMOVE 2
> > +static inline void *mremap(void *old_address, size_t old_size,
> > +                    size_t new_size, int flags, ... /* void
> *new_address */)
> > +{
> > +     return NULL;
> > +}
> > +
> > +/* FSR */
>
> Please just build the mremap file in xfs_io conditional.
>

Well, if I make io/mmap.c
​(​
where mremap is used
​) c​
onditional, then I need to
make multiple dummy calls
​ ​
or put ifdefs around every call from this file. So instead of a sing
​Well, if I make io/mmap.c, where mremap is used, conditional, then I need
to
make multiple dummy calls or put ifdefs around every call from that file.
So instead of a single dummy call and two defines, I ends with more
changes...​

IOW, I don't see any file I could remove from xfs_io without bigger changes.



>
> > +typedef int __fsblkcnt_t;
> > +typedef int __fsfilcnt_t;
> > +typedef long long int __fsblkcnt64_t;
> > +typedef long long int __fsfilcnt64_t;
> > +
> > +struct statvfs64
> > +{
> > +     unsigned long int f_bsize;
> > +     unsigned long int f_frsize;
> > +     __fsblkcnt64_t f_blocks;
> > +     __fsblkcnt64_t f_bfree;
> > +     __fsblkcnt64_t f_bavail;
> > +     __fsfilcnt64_t f_files;
> > +     __fsfilcnt64_t f_ffree;
> > +     __fsfilcnt64_t f_favail;
> > +     unsigned long int f_fsid;
> > +     int __f_unused;
> > +     unsigned long int f_flag;
> > +     unsigned long int f_namemax;
> > +     int __f_spare[6];
> > +};
>
> Does MacOS support statvfs? or statfs?  We should use the proper API
> here instead of a dummy.  Or maybe just not build fsr on OSX for now,
> as that would solve the fsetxattr issue as well.
>
>
​Now, this is what stopped me. As far as I can tell, simple

#define statvfs64 statfs

do the job, as Mac has the struct and the call. But statfs on Mac is missing
f_frsize and related members. I tried to make something with it, but I run
out of ideas others than redefine the struct...

​I still don't like the idea of removing fsr from OSX build, but if the
amount
of dummies is too big, it may end that way... :-(​

​Cheers,
Jan​

-- 
Jan Tulak
jtulak at redhat.com / jan at tulak.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20150824/e40b3656/attachment.html>