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

Jan Tulak
2015-08-24T12:54:06Z

[-- Attachment #1.1: Type: text/plain, Size: 2885 bytes --]

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@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@redhat.com / jan@tulak.me

[-- Attachment #1.2: Type: text/html, Size: 6270 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]