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

[Jan Tulak <jtulak@xxxxxxxxxx>]

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@xxxxxxxxxxxxx> 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@xxxxxxxxxxÂ/ jan@xxxxxxxx