* [PATCH 01/11] xfsprogs: undefined variable fix
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 19:22 ` Christoph Hellwig
2015-08-17 16:23 ` [PATCH 02/11] xfsprogs: Add ifdef dirent checks where it was missing Jan Tulak
` (10 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
Typo fix, which wasn't caught earlier due to #ifdef branching. The
'rmnttomname' does not exists anywhere and looks like a hybrid between
rmntfromname and rmntonname. And because the previous 'if' has
'fromname' on both arguments of realpath, I choosed the same approach
when fixing it.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
---
libxcmd/paths.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libxcmd/paths.c b/libxcmd/paths.c
index c56b06b..5c65737 100644
--- a/libxcmd/paths.c
+++ b/libxcmd/paths.c
@@ -364,7 +364,7 @@ fs_table_initialise_mounts(
continue;
if (!realpath(stats[i].f_mntfromname, rmntfromname))
continue;
- if (!realpath(stats[i].f_mntonname, rmnttomname)))
+ if (!realpath(stats[i].f_mntonname, rmntonname))
continue;
if (path &&
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 02/11] xfsprogs: Add ifdef dirent checks where it was missing
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
2015-08-17 16:23 ` [PATCH 01/11] xfsprogs: undefined variable fix Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 19:23 ` Christoph Hellwig
2015-08-17 16:23 ` [PATCH 03/11] xfsprogs: Change OS X-specific CFLAGS/LDFLAGS Jan Tulak
` (9 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
Add check for _DIRENT_HAVED_RECLEN/_OFF to read_directory().
In dump_dirent() these checks already are used, but they were
missing in read_directory.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
---
io/readdir.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/io/readdir.c b/io/readdir.c
index 7b0edbc..151b72e 100644
--- a/io/readdir.c
+++ b/io/readdir.c
@@ -103,12 +103,24 @@ read_directory(
if (!dirent)
break;
+#ifdef _DIRENT_HAVE_D_RECLEN
*total += dirent->d_reclen;
+#else
+ *total += dirent->d_namlen + sizeof(*dirent);
+#endif
count++;
if (dump) {
dump_dirent(offset, dirent);
+#ifdef _DIRENT_HAVE_D_OFF
offset = dirent->d_off;
+#else
+ /* Some platforms don't have dirent->d_off, but because
+ * it is used only for dumping the value, it should be
+ * safe to only set it to zero in such case.
+ */
+ offset = 0;
+#endif
}
}
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 02/11] xfsprogs: Add ifdef dirent checks where it was missing
2015-08-17 16:23 ` [PATCH 02/11] xfsprogs: Add ifdef dirent checks where it was missing Jan Tulak
@ 2015-08-17 19:23 ` Christoph Hellwig
2015-08-18 6:49 ` Jan Tulak
0 siblings, 1 reply; 42+ messages in thread
From: Christoph Hellwig @ 2015-08-17 19:23 UTC (permalink / raw)
To: Jan Tulak; +Cc: hch, xfs
On Mon, Aug 17, 2015 at 06:23:17PM +0200, Jan Tulak wrote:
> Add check for _DIRENT_HAVED_RECLEN/_OFF to read_directory().
> In dump_dirent() these checks already are used, but they were
> missing in read_directory.
>
> Signed-off-by: Jan Tulak <jtulak@redhat.com>
Looks fine,
Reviewed-by: Christoph Hellwig <hch@lst.de>
(and didn't I review this one previously?)
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 02/11] xfsprogs: Add ifdef dirent checks where it was missing
2015-08-17 19:23 ` Christoph Hellwig
@ 2015-08-18 6:49 ` Jan Tulak
0 siblings, 0 replies; 42+ messages in thread
From: Jan Tulak @ 2015-08-18 6:49 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs-oss
[-- Attachment #1.1: Type: text/plain, Size: 361 bytes --]
On Mon, Aug 17, 2015 at 9:23 PM, Christoph Hellwig <hch@infradead.org>
wrote:
>
> Looks fine,
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
Thanks.
>
> (and didn't I review this one previously?)
>
I think not this last iteration, with the d_reclen approximation. Or at
least I didn't get any reply to that.
Cheers,
Jan
--
Jan Tulak
jtulak@redhat.com
[-- Attachment #1.2: Type: text/html, Size: 1197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 03/11] xfsprogs: Change OS X-specific CFLAGS/LDFLAGS
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
2015-08-17 16:23 ` [PATCH 01/11] xfsprogs: undefined variable fix Jan Tulak
2015-08-17 16:23 ` [PATCH 02/11] xfsprogs: Add ifdef dirent checks where it was missing Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 16:23 ` [PATCH 04/11] xfsprogs: Add includes required for OS X builds Jan Tulak
` (8 subsequent siblings)
11 siblings, 0 replies; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
OS X uses clang as a default compiler.
So remove incompatible options.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
include/builddefs.in | 2 +-
libhandle/Makefile | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/builddefs.in b/include/builddefs.in
index cdf2d41..c644a17 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -118,7 +118,7 @@ ifeq ($(PKG_PLATFORM),gnukfreebsd)
PCFLAGS = -D_GNU_SOURCE $(GCCFLAGS)
endif
ifeq ($(PKG_PLATFORM),darwin)
-PCFLAGS = -traditional-cpp $(GCCFLAGS)
+PCFLAGS = $(GCCFLAGS)
DEPENDFLAGS = -D__APPLE__
endif
ifeq ($(PKG_PLATFORM),irix)
diff --git a/libhandle/Makefile b/libhandle/Makefile
index cc4ad1d..fe1a2af 100644
--- a/libhandle/Makefile
+++ b/libhandle/Makefile
@@ -10,7 +10,11 @@ LT_CURRENT = 1
LT_REVISION = 3
LT_AGE = 0
+ifeq ($(PKG_PLATFORM),darwin)
+LTLDFLAGS += -Wl,libhandle.sym
+else
LTLDFLAGS += -Wl,--version-script,libhandle.sym
+endif
CFILES = handle.c jdm.c
LSRCFILES = libhandle.sym
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 04/11] xfsprogs: Add includes required for OS X builds
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
` (2 preceding siblings ...)
2015-08-17 16:23 ` [PATCH 03/11] xfsprogs: Change OS X-specific CFLAGS/LDFLAGS Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 19:23 ` Christoph Hellwig
2015-08-17 16:23 ` [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support Jan Tulak
` (7 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
Signed-off-by: Jan Tulak <jtulak@redhat.com>
---
include/darwin.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/include/darwin.h b/include/darwin.h
index abdf4e3..8b5a661 100644
--- a/include/darwin.h
+++ b/include/darwin.h
@@ -18,12 +18,20 @@
#ifndef __XFS_DARWIN_H__
#define __XFS_DARWIN_H__
+#include <unistd.h>
+#include <sys/types.h>
+#include <string.h>
#include <uuid/uuid.h>
#include <libgen.h>
#include <sys/vm.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <sys/mount.h>
+#include <sys/types.h>
+#include <ftw.h>
+#include <mach/mach_time.h>
+#include <inttypes.h>
+#include <stdio.h>
#include <machine/endian.h>
#define __BYTE_ORDER BYTE_ORDER
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
` (3 preceding siblings ...)
2015-08-17 16:23 ` [PATCH 04/11] xfsprogs: Add includes required for OS X builds Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 19:32 ` Christoph Hellwig
2015-08-18 21:45 ` Dave Chinner
2015-08-17 16:23 ` [PATCH 06/11] xfsprogs: Add mntent.h check into autoconf Jan Tulak
` (6 subsequent siblings)
11 siblings, 2 replies; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
Add and update various API, macros and types where is some change
in OS X or xfsprogs. Most changes are in darwin.h.
Add dummy implementations where native support is nonexistent
and the tools are not expected to work anyway, so all tools can be
at least compiled.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
fsr/xfs_fsr.c | 8 +++
include/darwin.h | 153 +++++++++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 145 insertions(+), 16 deletions(-)
diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c
index 7c1d776..b4ff136 100644
--- a/fsr/xfs_fsr.c
+++ b/fsr/xfs_fsr.c
@@ -43,6 +43,14 @@
#define _PATH_FSRLAST "/var/tmp/.fsrlast_xfs"
#define _PATH_PROC_MOUNTS "/proc/mounts"
+#ifdef USE_DUMMY_XATTR
+ /* OS X has fsetxattr with different number of arguments.
+ * Because it won't work anyway (no fstab/mtab and so on),
+ * hijack the call to a dummy function so it can at least
+ * compile.
+ */
+# define fsetxattr(a,b,c,d,e) dummy_fsetxattr(a,b,c,d,e)
+#endif
char *progname;
diff --git a/include/darwin.h b/include/darwin.h
index 8b5a661..775dfc8 100644
--- a/include/darwin.h
+++ b/include/darwin.h
@@ -76,45 +76,37 @@ static __inline__ void platform_getoptreset(void)
static __inline__ int platform_uuid_compare(uuid_t *uu1, uuid_t *uu2)
{
- return uuid_compare(uu1, uu2, NULL);
+ return uuid_compare((const unsigned char *) uu1, (const unsigned char*) uu2);
}
static __inline__ void platform_uuid_unparse(uuid_t *uu, char *buffer)
{
- uint32_t status;
- char *s;
- uuid_to_string(uu, &s, &status);
- if (status == uuid_s_ok)
- strcpy(buffer, s);
- else buffer[0] = '\0';
- free(s);
+ uuid_unparse(*uu, buffer);
}
static __inline__ int platform_uuid_parse(char *buffer, uuid_t *uu)
{
- uint32_t status;
- uuid_from_string(buffer, uu, &status);
- return (status == uuid_s_ok);
+ return uuid_parse(buffer, *uu);
}
static __inline__ int platform_uuid_is_null(uuid_t *uu)
{
- return uuid_is_nil(uu, NULL);
+ return uuid_is_null(*uu);
}
static __inline__ void platform_uuid_generate(uuid_t *uu)
{
- uuid_create(uu, NULL);
+ uuid_generate(*uu);
}
static __inline__ void platform_uuid_clear(uuid_t *uu)
{
- uuid_create_nil(uu, NULL);
+ uuid_clear(*uu);
}
static __inline__ void platform_uuid_copy(uuid_t *dst, uuid_t *src)
{
- memcpy(dst, src, sizeof(uuid_t));
+ uuid_copy(*dst, *src);
}
typedef unsigned char __u8;
@@ -159,11 +151,13 @@ typedef int64_t xfs_daddr_t;
#define O_SYNC 0
#endif
-#define ENOATTR 989 /* Attribute not found */
#define EFSCORRUPTED 990 /* Filesystem is corrupted */
#define EFSBADCRC 991 /* Bad CRC detected */
#define constpp char * const *
+#define XATTR_SIZE_MAX 65536 /* size of an extended attribute value (64k) */
+#define XATTR_LIST_MAX 65536 /* size of extended attribute namelist (64k) */
+
#define HAVE_FID 1
static __inline__ int
@@ -172,4 +166,131 @@ platform_discard_blocks(int fd, uint64_t start, uint64_t len)
return 0;
}
+
+/*
+ * Dummy POSIX timer replacement
+ */
+#define CLOCK_REALTIME 1
+typedef uint64_t timer_t;
+typedef double timer_c;
+typedef clock_id_t clockid_t;
+struct itimerspec
+ {
+ struct timespec it_interval;
+ struct timespec it_value;
+ };
+
+static inline int timer_create (clockid_t __clock_id,
+ struct sigevent *__restrict __evp,
+ timer_t *__restrict __timerid)
+{
+ return 0;
+}
+
+static inline int timer_settime (timer_t __timerid, int __flags,
+ const struct itimerspec *__restrict __value,
+ struct itimerspec *__restrict __ovalue)
+{
+ return 0;
+}
+
+static inline int timer_delete (timer_t __timerid)
+{
+ return 0;
+}
+
+static inline int timer_gettime (timer_t __timerid, struct itimerspec *__value)
+{
+ return 0;
+}
+
+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 */
+
+#define _PATH_MOUNTED "/etc/mtab"
+#define USE_DUMMY_XATTR
+
+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];
+};
+
+struct mntent
+{
+ char *mnt_fsname; /* Device or server for filesystem. */
+ char *mnt_dir; /* Directory mounted on. */
+ char *mnt_type; /* Type of filesystem: ufs, nfs, etc. */
+ char *mnt_opts; /* Comma-separated options for fs. */
+ int mnt_freq; /* Dump frequency (in days). */
+ int mnt_passno; /* Pass number for `fsck'. */
+};
+
+static inline FILE *setmntent(const char *filename, const char *type)
+{
+ return NULL;
+}
+
+static inline int endmntent(FILE *fp)
+{
+ return 0;
+}
+
+static inline struct mntent *getmntent(FILE *fp)
+{
+ return NULL;
+}
+
+static inline int addmntent(FILE *fp, const struct mntent *mnt)
+{
+ return 0;
+}
+
+static inline char *hasmntopt(const struct mntent *mnt, const char *opt)
+{
+ return NULL;
+}
+
+static inline int statvfs64 (const char *__restrict __file,
+ struct statvfs64 *__restrict __buf)
+{
+ return 0;
+}
+
+static inline int dummy_fsetxattr (int filedes, const char *name,
+ const void *value, size_t size, int flags)
+{
+ return 0;
+}
+
+
#endif /* __XFS_DARWIN_H__ */
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-17 16:23 ` [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support Jan Tulak
@ 2015-08-17 19:32 ` Christoph Hellwig
2015-08-18 0:17 ` Dave Chinner
2015-08-24 12:53 ` Jan Tulak
2015-08-18 21:45 ` Dave Chinner
1 sibling, 2 replies; 42+ messages in thread
From: Christoph Hellwig @ 2015-08-17 19:32 UTC (permalink / raw)
To: Jan Tulak; +Cc: hch, xfs
On Mon, Aug 17, 2015 at 06:23:20PM +0200, Jan Tulak wrote:
> Add and update various API, macros and types where is some change
> in OS X or xfsprogs. Most changes are in darwin.h.
>
> Add dummy implementations where native support is nonexistent
> and the tools are not expected to work anyway, so all tools can be
> at least compiled.
>
> Signed-off-by: Jan Tulak <jtulak@redhat.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
> fsr/xfs_fsr.c | 8 +++
> include/darwin.h | 153 +++++++++++++++++++++++++++++++++++++++++++++++++------
> 2 files changed, 145 insertions(+), 16 deletions(-)
>
> diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c
> index 7c1d776..b4ff136 100644
> --- a/fsr/xfs_fsr.c
> +++ b/fsr/xfs_fsr.c
> @@ -43,6 +43,14 @@
> #define _PATH_FSRLAST "/var/tmp/.fsrlast_xfs"
> #define _PATH_PROC_MOUNTS "/proc/mounts"
>
> +#ifdef USE_DUMMY_XATTR
> + /* OS X has fsetxattr with different number of arguments.
> + * Because it won't work anyway (no fstab/mtab and so on),
> + * hijack the call to a dummy function so it can at least
> + * compile.
> + */
> +# define fsetxattr(a,b,c,d,e) dummy_fsetxattr(a,b,c,d,e)
> +#endif
I don't think this is the right way to do it. I'd rather:
a) check for fsetxattr using autoconf, and
b) stub out the whole code calling it.
c) make this a patch on it's own
>
> char *progname;
>
> diff --git a/include/darwin.h b/include/darwin.h
> index 8b5a661..775dfc8 100644
> --- a/include/darwin.h
> +++ b/include/darwin.h
> @@ -76,45 +76,37 @@ static __inline__ void platform_getoptreset(void)
>
> static __inline__ int platform_uuid_compare(uuid_t *uu1, uuid_t *uu2)
> {
> - return uuid_compare(uu1, uu2, NULL);
> + return uuid_compare((const unsigned char *) uu1, (const unsigned char*) uu2);
Do you have any idea why MacOS defines a uuid_t, but wants unsigned
char arguments to uuid_compare?
Or given that the others work with pointer dereferences why doesn't:
return uuid_compare(*uu1, *uu2);
work?
Also please make the uuid changes a patch on it's own.
> -#define ENOATTR 989 /* Attribute not found */
> #define EFSCORRUPTED 990 /* Filesystem is corrupted */
> #define EFSBADCRC 991 /* Bad CRC detected */
> #define constpp char * const *
> +#define XATTR_SIZE_MAX 65536 /* size of an extended attribute value (64k) */
> +#define XATTR_LIST_MAX 65536 /* size of extended attribute namelist (64k) */
Eww, looks like we depend on these Linux values in the on disk
defintion. I think we need to add new XFS_XATTR_SIZE_MAX and
XFS_XATTR_LIST_MAX defintions to xfs_format.h and use them where
we currently use these.
> +/*
> + * Dummy POSIX timer replacement
> + */
> +#define CLOCK_REALTIME 1
> +typedef uint64_t timer_t;
> +typedef double timer_c;
> +typedef clock_id_t clockid_t;
> +struct itimerspec
> + {
> + struct timespec it_interval;
> + struct timespec it_value;
> + };
> +
> +static inline int timer_create (clockid_t __clock_id,
> + struct sigevent *__restrict __evp,
> + timer_t *__restrict __timerid)
> +{
> + return 0;
> +}
> +
> +static inline int timer_settime (timer_t __timerid, int __flags,
> + const struct itimerspec *__restrict __value,
> + struct itimerspec *__restrict __ovalue)
> +{
> + return 0;
> +}
> +
> +static inline int timer_delete (timer_t __timerid)
> +{
> + return 0;
> +}
> +
> +static inline int timer_gettime (timer_t __timerid, struct itimerspec *__value)
> +{
> + return 0;
> +}
I don't think these stubs will work. It might be worth to figure
out what people use as replacement for realtime clocks on MacOS
by searching various programming resoures on the internet.
> +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.
> +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.
> +struct mntent
> +{
Another fsr issue, right? Seems like it would need similar getmntinfo
based code. As a stopgap I'd suggest we stop building fsr on OSX for
now.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-17 19:32 ` Christoph Hellwig
@ 2015-08-18 0:17 ` Dave Chinner
2015-08-24 12:53 ` Jan Tulak
1 sibling, 0 replies; 42+ messages in thread
From: Dave Chinner @ 2015-08-18 0:17 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs, Jan Tulak
On Mon, Aug 17, 2015 at 12:32:23PM -0700, Christoph Hellwig wrote:
> On Mon, Aug 17, 2015 at 06:23:20PM +0200, Jan Tulak wrote:
>
> > +#define XATTR_SIZE_MAX 65536 /* size of an extended attribute value (64k) */
> > +#define XATTR_LIST_MAX 65536 /* size of extended attribute namelist (64k) */
>
> Eww, looks like we depend on these Linux values in the on disk
> defintion. I think we need to add new XFS_XATTR_SIZE_MAX and
> XFS_XATTR_LIST_MAX defintions to xfs_format.h and use them where
> we currently use these.
Yeah, that looks like something we need to fix.
> > +#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.
Probably should be done on an autconf rule.
>
> > +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.
Apparently so:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/statfs.2.html
Note that we'll need to define _DARWIN_USE_64_BIT_INODE for OS X to
work correctly.
> > +struct mntent
> > +{
>
> Another fsr issue, right? Seems like it would need similar getmntinfo
> based code. As a stopgap I'd suggest we stop building fsr on OSX for
> now.
That can be based on the HAVE_MNTENT autoconf detection....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-17 19:32 ` Christoph Hellwig
2015-08-18 0:17 ` Dave Chinner
@ 2015-08-24 12:53 ` Jan Tulak
1 sibling, 0 replies; 42+ messages in thread
From: Jan Tulak @ 2015-08-24 12:53 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs-oss
[-- 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 --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-17 16:23 ` [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support Jan Tulak
2015-08-17 19:32 ` Christoph Hellwig
@ 2015-08-18 21:45 ` Dave Chinner
2015-08-19 8:09 ` Christoph Hellwig
1 sibling, 1 reply; 42+ messages in thread
From: Dave Chinner @ 2015-08-18 21:45 UTC (permalink / raw)
To: Jan Tulak; +Cc: hch, xfs
On Mon, Aug 17, 2015 at 06:23:20PM +0200, Jan Tulak wrote:
> Add and update various API, macros and types where is some change
> in OS X or xfsprogs. Most changes are in darwin.h.
>
> Add dummy implementations where native support is nonexistent
> and the tools are not expected to work anyway, so all tools can be
> at least compiled.
>
> Signed-off-by: Jan Tulak <jtulak@redhat.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
Hmmm, looks like I accidentally comitted an earlier version of this
patch yesterday. Jan, can you send delta patches to what I committed
to address more recent review comments? Sorry, my bad.
-Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-18 21:45 ` Dave Chinner
@ 2015-08-19 8:09 ` Christoph Hellwig
2015-08-19 9:14 ` Jan Tulak
2015-08-19 10:26 ` Dave Chinner
0 siblings, 2 replies; 42+ messages in thread
From: Christoph Hellwig @ 2015-08-19 8:09 UTC (permalink / raw)
To: Dave Chinner; +Cc: hch, xfs, Jan Tulak
On Wed, Aug 19, 2015 at 07:45:57AM +1000, Dave Chinner wrote:
> Hmmm, looks like I accidentally comitted an earlier version of this
> patch yesterday. Jan, can you send delta patches to what I committed
> to address more recent review comments? Sorry, my bad.
Can you revert it for now? I think most of these changes are incorrect
and should either be dropped for now by disabling fsx or will need
a major rework.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-19 8:09 ` Christoph Hellwig
@ 2015-08-19 9:14 ` Jan Tulak
2015-08-19 9:19 ` Christoph Hellwig
2015-08-19 10:26 ` Dave Chinner
1 sibling, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-19 9:14 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs-oss
[-- Attachment #1.1: Type: text/plain, Size: 1513 bytes --]
On Wed, Aug 19, 2015 at 10:09 AM, Christoph Hellwig <hch@infradead.org>
wrote:
>
> On Wed, Aug 19, 2015 at 07:45:57AM +1000, Dave Chinner wrote:
> > Hmmm, looks like I accidentally comitted an earlier version of this
> > patch yesterday. Jan, can you send delta patches to what I committed
> > to address more recent review comments? Sorry, my bad.
I guess my chaotic versioning can be blamed. :-)
> Can you revert it for now? I think most of these changes are incorrect
I agree, revert seems like a better idea. Especially if we want to split
things
like removing the XATTR_ dependency move into standalone commits.
> and should either be dropped for now by disabling fsx
I proposed dropping some tools earlier, but there was a valid point about
the possibility to break something when not even trying to compile it.
i.e. with the XATTR_ -> XFS_XATTR mentioned in the first reply to this patch
(which I already moved to a separate patch), it is necessary to add
#include "xfs/xfs_arch.h"
#include "xfs/xfs_format.h"
into libhandle/handle.c. But
I found
this
when I tried to compile it. If it was
in fsr and fsr wasn't compiling, I would most likely send a patch which
would
be thrown
back
on my head immediately. ;-)
So I think
it is better to have "bad dummy stuff" than not compile it
at all
.
> or will need
a major rework.
Working on it. :-)
Cheers,
Jan
--
Jan Tulak
jtulak@redhat.com / jan@tulak.me
[-- Attachment #1.2: Type: text/html, Size: 2595 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-19 9:14 ` Jan Tulak
@ 2015-08-19 9:19 ` Christoph Hellwig
0 siblings, 0 replies; 42+ messages in thread
From: Christoph Hellwig @ 2015-08-19 9:19 UTC (permalink / raw)
To: Jan Tulak; +Cc: Christoph Hellwig, xfs-oss
On Wed, Aug 19, 2015 at 11:14:42AM +0200, Jan Tulak wrote:
> I proposed dropping some tools earlier, but there was a valid point about
> the possibility to break something when not even trying to compile it.
> i.e. with the XATTR_ -> XFS_XATTR mentioned in the first reply to this patch
> (which I already moved to a separate patch), it is necessary to add
>
> #include "xfs/xfs_arch.h"
> #include "xfs/xfs_format.h"
>
> into libhandle/handle.c. But
I think we'll need another define for libhandle - it's at least
in theory supposed to be a somewhat generic library. In fact using
the existing XATTR_ values sort of makes sense for libattr, so I'd
say define a LIBHANDE_ version as well.
> So I think
> ??? ???
> it is better to have "bad dummy stuff" than not compile it
> at all
In general yes, for fsr I don't think so. One is the pure amount
of broken stubs it would need, the second is that fsr is the only
program that requires a _mounted_ XFS file system anyway. Most other
programs just use the on disk format, or in case of xfs_io are useful
for any file system.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-19 8:09 ` Christoph Hellwig
2015-08-19 9:14 ` Jan Tulak
@ 2015-08-19 10:26 ` Dave Chinner
2015-08-20 0:22 ` Dave Chinner
1 sibling, 1 reply; 42+ messages in thread
From: Dave Chinner @ 2015-08-19 10:26 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs, Jan Tulak
On Wed, Aug 19, 2015 at 01:09:40AM -0700, Christoph Hellwig wrote:
> On Wed, Aug 19, 2015 at 07:45:57AM +1000, Dave Chinner wrote:
> > Hmmm, looks like I accidentally comitted an earlier version of this
> > patch yesterday. Jan, can you send delta patches to what I committed
> > to address more recent review comments? Sorry, my bad.
>
> Can you revert it for now? I think most of these changes are incorrect
> and should either be dropped for now by disabling fsx or will need
> a major rework.
I'll just rebase the for-next branch, I guess, and remove it
completely from the history. I've got another lockdep fix that needs
to be pushed before it all hits tomorrow's linux-next build, anyway.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-19 10:26 ` Dave Chinner
@ 2015-08-20 0:22 ` Dave Chinner
2015-08-20 7:33 ` Jan Tulak
0 siblings, 1 reply; 42+ messages in thread
From: Dave Chinner @ 2015-08-20 0:22 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jan Tulak, xfs
On Wed, Aug 19, 2015 at 08:26:23PM +1000, Dave Chinner wrote:
> On Wed, Aug 19, 2015 at 01:09:40AM -0700, Christoph Hellwig wrote:
> > On Wed, Aug 19, 2015 at 07:45:57AM +1000, Dave Chinner wrote:
> > > Hmmm, looks like I accidentally comitted an earlier version of this
> > > patch yesterday. Jan, can you send delta patches to what I committed
> > > to address more recent review comments? Sorry, my bad.
> >
> > Can you revert it for now? I think most of these changes are incorrect
> > and should either be dropped for now by disabling fsx or will need
> > a major rework.
>
> I'll just rebase the for-next branch, I guess, and remove it
> completely from the history. I've got another lockdep fix that needs
> to be pushed before it all hits tomorrow's linux-next build, anyway.
Getting my trees mixed up. I'll revert the patch on the next push.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-20 0:22 ` Dave Chinner
@ 2015-08-20 7:33 ` Jan Tulak
2015-08-21 0:43 ` Dave Chinner
0 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-20 7:33 UTC (permalink / raw)
To: Dave Chinner; +Cc: Christoph Hellwig, xfs-oss
[-- Attachment #1.1: Type: text/plain, Size: 1290 bytes --]
On Thu, Aug 20, 2015 at 2:22 AM, Dave Chinner <david@fromorbit.com> wrote:
> On Wed, Aug 19, 2015 at 08:26:23PM +1000, Dave Chinner wrote:
> > On Wed, Aug 19, 2015 at 01:09:40AM -0700, Christoph Hellwig wrote:
> > > On Wed, Aug 19, 2015 at 07:45:57AM +1000, Dave Chinner wrote:
> > > > Hmmm, looks like I accidentally comitted an earlier version of this
> > > > patch yesterday. Jan, can you send delta patches to what I committed
> > > > to address more recent review comments? Sorry, my bad.
> > >
> > > Can you revert it for now? I think most of these changes are incorrect
> > > and should either be dropped for now by disabling fsx or will need
> > > a major rework.
> >
> > I'll just rebase the for-next branch, I guess, and remove it
> > completely from the history. I've got another lockdep fix that needs
> > to be pushed before it all hits tomorrow's linux-next build, anyway.
>
> Getting my trees mixed up. I'll revert the patch on the next push.
And as I noticed, '
xfsprogs: Add includes required for OS X builds
' was also
selected in an older version. Other patches looks OK, though. :-)
Should I send delta patch for that one? It is just about three #includes.
Cheers,
Jan
--
Jan Tulak
jtulak@redhat.com / jan@tulak.me
[-- Attachment #1.2: Type: text/html, Size: 2627 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support
2015-08-20 7:33 ` Jan Tulak
@ 2015-08-21 0:43 ` Dave Chinner
0 siblings, 0 replies; 42+ messages in thread
From: Dave Chinner @ 2015-08-21 0:43 UTC (permalink / raw)
To: Jan Tulak; +Cc: Christoph Hellwig, xfs-oss
On Thu, Aug 20, 2015 at 09:33:33AM +0200, Jan Tulak wrote:
> On Thu, Aug 20, 2015 at 2:22 AM, Dave Chinner <david@fromorbit.com> wrote:
>
> > On Wed, Aug 19, 2015 at 08:26:23PM +1000, Dave Chinner wrote:
> > > On Wed, Aug 19, 2015 at 01:09:40AM -0700, Christoph Hellwig wrote:
> > > > On Wed, Aug 19, 2015 at 07:45:57AM +1000, Dave Chinner wrote:
> > > > > Hmmm, looks like I accidentally comitted an earlier version of this
> > > > > patch yesterday. Jan, can you send delta patches to what I committed
> > > > > to address more recent review comments? Sorry, my bad.
> > > >
> > > > Can you revert it for now? I think most of these changes are incorrect
> > > > and should either be dropped for now by disabling fsx or will need
> > > > a major rework.
> > >
> > > I'll just rebase the for-next branch, I guess, and remove it
> > > completely from the history. I've got another lockdep fix that needs
> > > to be pushed before it all hits tomorrow's linux-next build, anyway.
> >
> > Getting my trees mixed up. I'll revert the patch on the next push.
>
>
> And as I noticed, '
> xfsprogs: Add includes required for OS X builds
> ' was also
> selected in an older version. Other patches looks OK, though. :-)
> Should I send delta patch for that one? It is just about three #includes.
Yes.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 06/11] xfsprogs: Add mntent.h check into autoconf
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
` (4 preceding siblings ...)
2015-08-17 16:23 ` [PATCH 05/11] xfsprogs: missing and dummy calls for OS X support Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 19:32 ` Christoph Hellwig
2015-08-17 16:23 ` [PATCH 07/11] xfsprogs: Add fls " Jan Tulak
` (5 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
Signed-off-by: Jan Tulak <jtulak@redhat.com>
---
configure.ac | 1 +
fsr/xfs_fsr.c | 6 +++---
include/builddefs.in | 4 ++++
m4/package_libcdev.m4 | 8 ++++++++
4 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 530650b..0aba90c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -115,6 +115,7 @@ AC_HAVE_FALLOCATE
AC_HAVE_FIEMAP
AC_HAVE_PREADV
AC_HAVE_SYNC_FILE_RANGE
+AC_HAVE_MNTENT
AC_HAVE_BLKID_TOPO
AC_HAVE_READDIR
diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c
index b4ff136..4912b73 100644
--- a/fsr/xfs_fsr.c
+++ b/fsr/xfs_fsr.c
@@ -25,16 +25,16 @@
#include <fcntl.h>
#include <errno.h>
-#include <malloc.h>
-#include <mntent.h>
#include <syslog.h>
#include <signal.h>
#include <sys/ioctl.h>
#include <sys/wait.h>
-#include <sys/vfs.h>
#include <sys/statvfs.h>
#include <sys/xattr.h>
+#ifdef HAVE_MNTENT
+# include <mntent.h>
+#endif
#ifndef XFS_XFLAG_NODEFRAG
#define XFS_XFLAG_NODEFRAG 0x00002000 /* src dependancy, remove later */
diff --git a/include/builddefs.in b/include/builddefs.in
index c644a17..e522243 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -103,6 +103,7 @@ HAVE_FIEMAP = @have_fiemap@
HAVE_PREADV = @have_preadv@
HAVE_SYNC_FILE_RANGE = @have_sync_file_range@
HAVE_READDIR = @have_readdir@
+HAVE_MNTENT = @have_mntent@
GCCFLAGS = -funsigned-char -fno-strict-aliasing -Wall
# -Wbitwise -Wno-transparent-union -Wno-old-initializer -Wno-decl
@@ -130,6 +131,9 @@ PLDLIBS = -L/usr/local/lib -lintl
PCFLAGS = -I/usr/local/include $(GCCFLAGS)
DEPENDFLAGS = -D__FreeBSD__
endif
+ifeq ($(HAVE_MNTENT),yes)
+PCFLAGS+= -DHAVE_MNTENT
+endif
GCFLAGS = $(OPTIMIZER) $(DEBUG) \
-DVERSION=\"$(PKG_VERSION)\" -DLOCALEDIR=\"$(PKG_LOCALE_DIR)\" \
diff --git a/m4/package_libcdev.m4 b/m4/package_libcdev.m4
index 919ae0a..75aa61e 100644
--- a/m4/package_libcdev.m4
+++ b/m4/package_libcdev.m4
@@ -202,3 +202,11 @@ AC_DEFUN([AC_HAVE_READDIR],
AC_SUBST(have_readdir)
])
+#
+# Check if there is mntent.h
+#
+AC_DEFUN([AC_HAVE_MNTENT],
+ [ AC_CHECK_HEADERS(mntent.h,
+ have_mntent=yes)
+ AC_SUBST(have_mntent)
+ ])
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 07/11] xfsprogs: Add fls check into autoconf
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
` (5 preceding siblings ...)
2015-08-17 16:23 ` [PATCH 06/11] xfsprogs: Add mntent.h check into autoconf Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 19:32 ` Christoph Hellwig
2015-08-17 16:23 ` [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign Jan Tulak
` (4 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
Signed-off-by: Jan Tulak <jtulak@redhat.com>
---
configure.ac | 1 +
include/bitops.h | 2 ++
include/builddefs.in | 4 ++++
m4/package_libcdev.m4 | 12 ++++++++++++
4 files changed, 19 insertions(+)
diff --git a/configure.ac b/configure.ac
index 0aba90c..abb7904 100644
--- a/configure.ac
+++ b/configure.ac
@@ -116,6 +116,7 @@ AC_HAVE_FIEMAP
AC_HAVE_PREADV
AC_HAVE_SYNC_FILE_RANGE
AC_HAVE_MNTENT
+AC_HAVE_FLS
AC_HAVE_BLKID_TOPO
AC_HAVE_READDIR
diff --git a/include/bitops.h b/include/bitops.h
index 930f64a..44599a7 100644
--- a/include/bitops.h
+++ b/include/bitops.h
@@ -5,6 +5,7 @@
* fls: find last bit set.
*/
+#ifndef HAVE_FLS
static inline int fls(int x)
{
int r = 32;
@@ -32,6 +33,7 @@ static inline int fls(int x)
}
return r;
}
+#endif /* HAVE_FLS */
static inline int fls64(__u64 x)
{
diff --git a/include/builddefs.in b/include/builddefs.in
index e522243..8851956 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -104,6 +104,7 @@ HAVE_PREADV = @have_preadv@
HAVE_SYNC_FILE_RANGE = @have_sync_file_range@
HAVE_READDIR = @have_readdir@
HAVE_MNTENT = @have_mntent@
+HAVE_FLS = @have_fls@
GCCFLAGS = -funsigned-char -fno-strict-aliasing -Wall
# -Wbitwise -Wno-transparent-union -Wno-old-initializer -Wno-decl
@@ -131,6 +132,9 @@ PLDLIBS = -L/usr/local/lib -lintl
PCFLAGS = -I/usr/local/include $(GCCFLAGS)
DEPENDFLAGS = -D__FreeBSD__
endif
+ifeq ($(HAVE_FLS),yes)
+LCFLAGS+= -DHAVE_FLS
+endif
ifeq ($(HAVE_MNTENT),yes)
PCFLAGS+= -DHAVE_MNTENT
endif
diff --git a/m4/package_libcdev.m4 b/m4/package_libcdev.m4
index 75aa61e..4a96374 100644
--- a/m4/package_libcdev.m4
+++ b/m4/package_libcdev.m4
@@ -203,6 +203,18 @@ AC_DEFUN([AC_HAVE_READDIR],
])
#
+# Check if we have a flc call (Mac OS X)
+#
+AC_DEFUN([AC_HAVE_FLS],
+ [ AC_CHECK_DECL([fls],
+ have_fls=yes,
+ [],
+ [#include <string.h>]
+ )
+ AC_SUBST(have_fls)
+ ])
+
+#
# Check if there is mntent.h
#
AC_DEFUN([AC_HAVE_MNTENT],
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
` (6 preceding siblings ...)
2015-08-17 16:23 ` [PATCH 07/11] xfsprogs: Add fls " Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 19:36 ` Christoph Hellwig
2015-08-17 16:23 ` [PATCH 09/11] xfsprogs: prevent LIST_ macros conflicts Jan Tulak
` (3 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
Memalign from <malloc.h> was marked obsolete in favor of a posix
variant from <stdlib.h>. So replace all calls and remove <malloc.h>
includes. This also enhances support on other posix platforms,
which doesn't have <malloc.h>.
Because posix_memalign returns any error as a return code, not in
errno, change relevant checks in code (and add a missing one).
Signed-off-by: Jan Tulak <jtulak@redhat.com>
---
copy/xfs_copy.c | 2 +-
db/attrset.c | 2 +-
fsr/xfs_fsr.c | 3 ++-
include/darwin.h | 1 -
include/freebsd.h | 1 -
include/gnukfreebsd.h | 1 -
include/linux.h | 1 -
io/pread.c | 4 ++--
libxfs/rdwr.c | 12 ++++++++----
mkfs/xfs_mkfs.c | 3 ++-
repair/incore.c | 2 +-
repair/incore_ino.c | 7 ++++---
repair/phase1.c | 2 +-
repair/prefetch.c | 7 +++----
repair/sb.c | 10 +++++-----
rtcp/xfs_rtcp.c | 7 ++++++-
16 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/copy/xfs_copy.c b/copy/xfs_copy.c
index e13f468..8109ac5 100644
--- a/copy/xfs_copy.c
+++ b/copy/xfs_copy.c
@@ -333,7 +333,7 @@ wbuf *
wbuf_init(wbuf *buf, int data_size, int data_align, int min_io_size, int id)
{
ASSERT(data_size % BBSIZE == 0);
- while ((buf->data = memalign(data_align, data_size)) == NULL) {
+ while (posix_memalign((void**)&(buf->data), data_align, data_size)) {
data_size >>= 1;
if (data_size < min_io_size)
return NULL;
diff --git a/db/attrset.c b/db/attrset.c
index ec9da5a..539765f 100644
--- a/db/attrset.c
+++ b/db/attrset.c
@@ -141,7 +141,7 @@ attr_set_f(
name = argv[optind];
if (valuelen) {
- value = (char *)memalign(getpagesize(), valuelen);
+ posix_memalign((void**)&value, getpagesize(), valuelen);
if (!value) {
dbprintf(_("cannot allocate buffer (%d)\n"), valuelen);
goto out;
diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c
index 4912b73..ad52990 100644
--- a/fsr/xfs_fsr.c
+++ b/fsr/xfs_fsr.c
@@ -1306,7 +1306,8 @@ packfile(char *fname, char *tname, int fd,
dio.d_maxiosz, pagesize);
}
- if (!(fbuf = (char *)memalign(dio.d_mem, blksz_dio))) {
+ posix_memalign((void **)&fbuf, dio.d_mem, blksz_dio);
+ if (!fbuf) {
fsrprintf(_("could not allocate buf: %s\n"), tname);
goto out;
}
diff --git a/include/darwin.h b/include/darwin.h
index 775dfc8..e3ec863 100644
--- a/include/darwin.h
+++ b/include/darwin.h
@@ -141,7 +141,6 @@ typedef int64_t xfs_daddr_t;
#define pwrite64 pwrite
#define ftruncate64 ftruncate
#define fdatasync fsync
-#define memalign(a,sz) valloc(sz)
#define O_LARGEFILE 0
#ifndef O_DIRECT
diff --git a/include/freebsd.h b/include/freebsd.h
index 902b940..7289159 100644
--- a/include/freebsd.h
+++ b/include/freebsd.h
@@ -40,7 +40,6 @@
#define pwrite64 pwrite
#define pread64 pread
#define fdatasync fsync
-#define memalign(a,sz) valloc(sz)
#define constpp char * const *
diff --git a/include/gnukfreebsd.h b/include/gnukfreebsd.h
index 95c4c13..4605234 100644
--- a/include/gnukfreebsd.h
+++ b/include/gnukfreebsd.h
@@ -22,7 +22,6 @@
#include <sys/vfs.h>
#include <sys/ioctl.h>
#include <sys/sysmacros.h>
-#include <malloc.h>
#include <getopt.h>
#include <endian.h>
#include <sys/stat.h>
diff --git a/include/linux.h b/include/linux.h
index 8804c2d..7493b76 100644
--- a/include/linux.h
+++ b/include/linux.h
@@ -24,7 +24,6 @@
#include <sys/sysmacros.h>
#include <sys/stat.h>
#include <inttypes.h>
-#include <malloc.h>
#include <getopt.h>
#include <errno.h>
#include <endian.h>
diff --git a/io/pread.c b/io/pread.c
index 1c77c41..74ba47e 100644
--- a/io/pread.c
+++ b/io/pread.c
@@ -77,7 +77,7 @@ alloc_iovec(
buffersize = 0;
for (i = 0; i < vectors; i++) {
- iov[i].iov_base = memalign(pagesize, bsize);
+ posix_memalign((void**)&(iov[i].iov_base), pagesize, bsize);
if (!iov[i].iov_base) {
perror("memalign");
goto unwind;
@@ -108,7 +108,7 @@ alloc_buffer(
if (bsize > highwater) {
if (buffer)
free(buffer);
- buffer = memalign(pagesize, bsize);
+ posix_memalign((void**)&buffer, pagesize, bsize);
if (!buffer) {
perror("memalign");
highwater = buffersize = 0;
diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c
index 4f8212f..7884cf8 100644
--- a/libxfs/rdwr.c
+++ b/libxfs/rdwr.c
@@ -74,12 +74,14 @@ libxfs_device_zero(struct xfs_buftarg *btp, xfs_daddr_t start, uint len)
ssize_t zsize, bytes;
char *z;
int fd;
+ int ret;
zsize = min(BDSTRAT_SIZE, BBTOB(len));
- if ((z = memalign(libxfs_device_alignment(), zsize)) == NULL) {
+ ret = posix_memalign((void **)&z, libxfs_device_alignment(), zsize);
+ if (!z) {
fprintf(stderr,
_("%s: %s can't memalign %d bytes: %s\n"),
- progname, __FUNCTION__, (int)zsize, strerror(errno));
+ progname, __FUNCTION__, (int)zsize, strerror(ret));
exit(1);
}
memset(z, 0, zsize);
@@ -409,6 +411,7 @@ static void
__initbuf(xfs_buf_t *bp, struct xfs_buftarg *btp, xfs_daddr_t bno,
unsigned int bytes)
{
+ int ret;
bp->b_flags = 0;
bp->b_bn = bno;
bp->b_bcount = bytes;
@@ -416,12 +419,13 @@ __initbuf(xfs_buf_t *bp, struct xfs_buftarg *btp, xfs_daddr_t bno,
bp->b_target = btp;
bp->b_error = 0;
if (!bp->b_addr)
- bp->b_addr = memalign(libxfs_device_alignment(), bytes);
+ ret = posix_memalign((void**)&(bp->b_addr),
+ libxfs_device_alignment(), bytes);
if (!bp->b_addr) {
fprintf(stderr,
_("%s: %s can't memalign %u bytes: %s\n"),
progname, __FUNCTION__, bytes,
- strerror(errno));
+ strerror(ret));
exit(1);
}
memset(bp->b_addr, 0, bytes);
diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
index 69d61c7..d349b4f 100644
--- a/mkfs/xfs_mkfs.c
+++ b/mkfs/xfs_mkfs.c
@@ -770,7 +770,8 @@ zero_old_xfs_structures(
* read in existing filesystem superblock, use its geometry
* settings and zero the existing secondary superblocks.
*/
- buf = memalign(libxfs_device_alignment(), new_sb->sb_sectsize);
+ posix_memalign((void**)&buf, libxfs_device_alignment(),
+ new_sb->sb_sectsize);
if (!buf) {
fprintf(stderr,
_("error reading existing superblock -- failed to memalign buffer\n"));
diff --git a/repair/incore.c b/repair/incore.c
index cb57316..81d3b8c 100644
--- a/repair/incore.c
+++ b/repair/incore.c
@@ -224,7 +224,7 @@ init_rt_bmap(
rt_bmap_size = roundup(mp->m_sb.sb_rextents / (NBBY / XR_BB),
sizeof(__uint64_t));
- rt_bmap = memalign(sizeof(__uint64_t), rt_bmap_size);
+ posix_memalign((void**)&rt_bmap, sizeof(__uint64_t), rt_bmap_size);
if (!rt_bmap) {
do_error(
_("couldn't allocate realtime block map, size = %" PRIu64 "\n"),
diff --git a/repair/incore_ino.c b/repair/incore_ino.c
index 32d7678..dd95996 100644
--- a/repair/incore_ino.c
+++ b/repair/incore_ino.c
@@ -626,8 +626,8 @@ set_inode_parent(
irec->ino_un.plist = ptbl;
ptbl->pmask = 1LL << offset;
- ptbl->pentries = (xfs_ino_t*)memalign(sizeof(xfs_ino_t),
- sizeof(xfs_ino_t));
+ posix_memalign((void**)&(ptbl->pentries),sizeof(xfs_ino_t),
+ sizeof(xfs_ino_t));
if (!ptbl->pentries)
do_error(_("couldn't memalign pentries table\n"));
#ifdef DEBUG
@@ -673,7 +673,8 @@ set_inode_parent(
#endif
ASSERT(cnt >= target);
- tmp = (xfs_ino_t*)memalign(sizeof(xfs_ino_t), (cnt + 1) * sizeof(xfs_ino_t));
+ posix_memalign((void**)&tmp, sizeof(xfs_ino_t),
+ (cnt + 1) * sizeof(xfs_ino_t));
if (!tmp)
do_error(_("couldn't memalign pentries table\n"));
diff --git a/repair/phase1.c b/repair/phase1.c
index 126d0b3..7a1fc7d 100644
--- a/repair/phase1.c
+++ b/repair/phase1.c
@@ -35,7 +35,7 @@ alloc_ag_buf(int size)
{
char *bp;
- bp = (char *)memalign(libxfs_device_alignment(), size);
+ posix_memalign((void**)&bp, libxfs_device_alignment(), size);
if (!bp)
do_error(_("could not allocate ag header buffer (%d bytes)\n"),
size);
diff --git a/repair/prefetch.c b/repair/prefetch.c
index 8b261ae..c6c9450 100644
--- a/repair/prefetch.c
+++ b/repair/prefetch.c
@@ -631,10 +631,9 @@ pf_io_worker(
void *param)
{
prefetch_args_t *args = param;
- void *buf = memalign(libxfs_device_alignment(),
- pf_max_bytes);
-
- if (buf == NULL)
+ void *buf;
+ posix_memalign((void**)&buf, libxfs_device_alignment(), pf_max_bytes);
+ if (!buf)
return NULL;
pthread_mutex_lock(&args->lock);
diff --git a/repair/sb.c b/repair/sb.c
index 4eef14a..cf1ea8b 100644
--- a/repair/sb.c
+++ b/repair/sb.c
@@ -102,7 +102,7 @@ find_secondary_sb(xfs_sb_t *rsb)
do_warn(_("\nattempting to find secondary superblock...\n"));
- sb = (xfs_sb_t *)memalign(libxfs_device_alignment(), BSIZE);
+ posix_memalign((void**)&sb, libxfs_device_alignment(), BSIZE);
if (!sb) {
do_error(
_("error finding secondary superblock -- failed to memalign buffer\n"));
@@ -438,8 +438,8 @@ write_primary_sb(xfs_sb_t *sbp, int size)
if (no_modify)
return;
- buf = memalign(libxfs_device_alignment(), size);
- if (buf == NULL) {
+ posix_memalign((void**)&buf, libxfs_device_alignment(), size);
+ if (!buf) {
do_error(_("failed to memalign superblock buffer\n"));
return;
}
@@ -472,8 +472,8 @@ get_sb(xfs_sb_t *sbp, xfs_off_t off, int size, xfs_agnumber_t agno)
int error, rval;
xfs_dsb_t *buf;
- buf = memalign(libxfs_device_alignment(), size);
- if (buf == NULL) {
+ posix_memalign((void**)&buf, libxfs_device_alignment(), size);
+ if (!buf) {
do_error(
_("error reading superblock %u -- failed to memalign buffer\n"),
agno);
diff --git a/rtcp/xfs_rtcp.c b/rtcp/xfs_rtcp.c
index f604b46..e2e3ece 100644
--- a/rtcp/xfs_rtcp.c
+++ b/rtcp/xfs_rtcp.c
@@ -327,7 +327,12 @@ rtcp( char *source, char *target, int fextsize)
}
iosz = dioattr.d_miniosz;
- fbuf = memalign( dioattr.d_mem, iosz);
+ posix_memalign((void**)&fbuf, dioattr.d_mem, iosz);
+ if (!fbuf) {
+ perror(
+ _("error finding secondary superblock -- failed to memalign buffer\n"));
+ exit(1);
+ }
memset(fbuf, 0, iosz);
/*
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign
2015-08-17 16:23 ` [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign Jan Tulak
@ 2015-08-17 19:36 ` Christoph Hellwig
2015-08-18 7:04 ` Jan Tulak
0 siblings, 1 reply; 42+ messages in thread
From: Christoph Hellwig @ 2015-08-17 19:36 UTC (permalink / raw)
To: Jan Tulak; +Cc: hch, xfs
On Mon, Aug 17, 2015 at 06:23:23PM +0200, Jan Tulak wrote:
> Memalign from <malloc.h> was marked obsolete in favor of a posix
> variant from <stdlib.h>. So replace all calls and remove <malloc.h>
> includes. This also enhances support on other posix platforms,
> which doesn't have <malloc.h>.
>
> Because posix_memalign returns any error as a return code, not in
> errno, change relevant checks in code (and add a missing one).
I have to say I hate the posix_memalign calling convention. Any chance
you could just provide a memalign impementation using posix_memalign for
MacOS?
Something like:
static inline void *memalign(size_t alignment, size_t size)
{
int error;
void *buf;
error = posix_memalign(&buf, alignment, size);
if (error)
errno = error;
buf = NULL;
}
return buf;
}
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign
2015-08-17 19:36 ` Christoph Hellwig
@ 2015-08-18 7:04 ` Jan Tulak
2015-08-18 8:20 ` Dave Chinner
0 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-18 7:04 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs-oss
[-- Attachment #1.1: Type: text/plain, Size: 1727 bytes --]
On Mon, Aug 17, 2015 at 9:36 PM, Christoph Hellwig <hch@infradead.org>
wrote:
> On Mon, Aug 17, 2015 at 06:23:23PM +0200, Jan Tulak wrote:
> > Memalign from <malloc.h> was marked obsolete in favor of a posix
> > variant from <stdlib.h>. So replace all calls and remove <malloc.h>
> > includes. This also enhances support on other posix platforms,
> > which doesn't have <malloc.h>.
> >
> > Because posix_memalign returns any error as a return code, not in
> > errno, change relevant checks in code (and add a missing one).
>
> I have to say I hate the posix_memalign calling convention. Any chance
> you could just provide a memalign impementation using posix_memalign for
> MacOS?
>
I thought about it. However, with memalign from malloc marked obsolete
(and with posix_memalign having guaranteed alignment restrictions [1]), I
saw it better
to use the posix variant everywhere.
I could make a wrapper simulating the old memalign behaviour, but I don't
think it would make sense.
I searched for this, but didn't find any reasonable answer:
How long can be things in standard libraries marked obsolete before
removing?
Cheers,
Jan
[1] man memalign:
On many systems there are alignment restrictions, for example, on
buf‐
fers used for direct block device I/O. POSIX specifies the
path‐
conf(path,_PC_REC_XFER_ALIGN) call that tells what alignment is
needed.
Now one can use posix_memalign() to satisfy this requirement.
posix_memalign() verifies that alignment matches the
requirements
detailed above. memalign() may not check that the alignment
argument
is correct.
--
Jan Tulak
jtulak@redhat.com
[-- Attachment #1.2: Type: text/html, Size: 2552 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign
2015-08-18 7:04 ` Jan Tulak
@ 2015-08-18 8:20 ` Dave Chinner
2015-08-18 8:33 ` Jan Tulak
0 siblings, 1 reply; 42+ messages in thread
From: Dave Chinner @ 2015-08-18 8:20 UTC (permalink / raw)
To: Jan Tulak; +Cc: Christoph Hellwig, xfs-oss
On Tue, Aug 18, 2015 at 09:04:24AM +0200, Jan Tulak wrote:
> On Mon, Aug 17, 2015 at 9:36 PM, Christoph Hellwig <hch@infradead.org>
> wrote:
>
> > On Mon, Aug 17, 2015 at 06:23:23PM +0200, Jan Tulak wrote:
> > > Memalign from <malloc.h> was marked obsolete in favor of a posix
> > > variant from <stdlib.h>. So replace all calls and remove <malloc.h>
> > > includes. This also enhances support on other posix platforms,
> > > which doesn't have <malloc.h>.
> > >
> > > Because posix_memalign returns any error as a return code, not in
> > > errno, change relevant checks in code (and add a missing one).
> >
> > I have to say I hate the posix_memalign calling convention. Any chance
> > you could just provide a memalign impementation using posix_memalign for
> > MacOS?
> >
>
> I thought about it. However, with memalign from malloc marked obsolete
> (and with posix_memalign having guaranteed alignment restrictions [1]), I
> saw it better
> to use the posix variant everywhere.
Putting a sane wrapper around an nasty library function is just
fine. The memalign wrapper makes sense from this perspective - even
gcc can't tell if variables passed to posix_memalign are correctly
initialised or not, whereas no such problems exist for memalign().
> I could make a wrapper simulating the old memalign behaviour, but I don't
> think it would make sense.
I think it makes more sense than using posix_memalign() everywhere
and then ignoring the return variable that tells you it failed...
> I searched for this, but didn't find any reasonable answer:
> How long can be things in standard libraries marked obsolete before
> removing?
With a wrapper, we don't care.
> [1] man memalign:
> On many systems there are alignment restrictions, for example, on buf-
> fers used for direct block device I/O. POSIX specifies the path-
> conf(path,_PC_REC_XFER_ALIGN) call that tells what alignment is needed.
> Now one can use posix_memalign() to satisfy this requirement.
>
> posix_memalign() verifies that alignment matches the requirements
> detailed above. memalign() may not check that the alignment argument
> is correct.
Yes, you can get it wrong with memalign. But we don't, because we
follow the rules for DIO buffer alignment and set it correctly.
Being able to directly control the alignment of the memory buffer is
a reason for using memalign() over posix_memalign(), not the other
way around.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign
2015-08-18 8:20 ` Dave Chinner
@ 2015-08-18 8:33 ` Jan Tulak
2015-08-18 22:01 ` Dave Chinner
0 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-18 8:33 UTC (permalink / raw)
To: Dave Chinner; +Cc: Christoph Hellwig, xfs-oss
[-- Attachment #1.1: Type: text/plain, Size: 2242 bytes --]
On Tue, Aug 18, 2015 at 10:20 AM, Dave Chinner <david@fromorbit.com> wrote:
> On Tue, Aug 18, 2015 at 09:04:24AM +0200, Jan Tulak wrote:
> > I thought about it. However, with memalign from malloc marked obsolete
> > (and with posix_memalign having guaranteed alignment restrictions [1]), I
> > saw it better
> > to use the posix variant everywhere.
>
> Putting a sane wrapper around an nasty library function is just
> fine. The memalign wrapper makes sense from this perspective - even
> gcc can't tell if variables passed to posix_memalign are correctly
> initialised or not, whereas no such problems exist for memalign().
>
> > I could make a wrapper simulating the old memalign behaviour, but I don't
> > think it would make sense.
>
> I think it makes more sense than using posix_memalign() everywhere
> and then ignoring the return variable that tells you it failed...
>
> > I searched for this, but didn't find any reasonable answer:
> > How long can be things in standard libraries marked obsolete before
> > removing?
>
> With a wrapper, we don't care.
>
> > [1] man memalign:
> > On many systems there are alignment restrictions, for example, on
> buf-
> > fers used for direct block device I/O. POSIX specifies the
> path-
> > conf(path,_PC_REC_XFER_ALIGN) call that tells what alignment is
> needed.
> > Now one can use posix_memalign() to satisfy this requirement.
> >
> > posix_memalign() verifies that alignment matches the
> requirements
> > detailed above. memalign() may not check that the alignment
> argument
> > is correct.
>
> Yes, you can get it wrong with memalign. But we don't, because we
> follow the rules for DIO buffer alignment and set it correctly.
> Being able to directly control the alignment of the memory buffer is
> a reason for using memalign() over posix_memalign(), not the other
> way around.
>
So a wrapper used on all platforms is an acceptable solution? All right,
this explanation makes sense. I will change it that way. The only question
I have now is whether to use posix_memalign on every platform, or whether to
make it platform_memalign and use the old memalign inside for Linux.
Cheers,
Jan
--
Jan Tulak
jtulak@redhat.com
[-- Attachment #1.2: Type: text/html, Size: 3355 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign
2015-08-18 8:33 ` Jan Tulak
@ 2015-08-18 22:01 ` Dave Chinner
2015-08-19 8:06 ` Jan Tulak
0 siblings, 1 reply; 42+ messages in thread
From: Dave Chinner @ 2015-08-18 22:01 UTC (permalink / raw)
To: Jan Tulak; +Cc: Christoph Hellwig, xfs-oss
On Tue, Aug 18, 2015 at 10:33:49AM +0200, Jan Tulak wrote:
> On Tue, Aug 18, 2015 at 10:20 AM, Dave Chinner <david@fromorbit.com> wrote:
>
> > On Tue, Aug 18, 2015 at 09:04:24AM +0200, Jan Tulak wrote:
> > > I thought about it. However, with memalign from malloc marked obsolete
> > > (and with posix_memalign having guaranteed alignment restrictions [1]), I
> > > saw it better
> > > to use the posix variant everywhere.
> >
> > Putting a sane wrapper around an nasty library function is just
> > fine. The memalign wrapper makes sense from this perspective - even
> > gcc can't tell if variables passed to posix_memalign are correctly
> > initialised or not, whereas no such problems exist for memalign().
> >
> > > I could make a wrapper simulating the old memalign behaviour, but I don't
> > > think it would make sense.
> >
> > I think it makes more sense than using posix_memalign() everywhere
> > and then ignoring the return variable that tells you it failed...
> >
> > > I searched for this, but didn't find any reasonable answer:
> > > How long can be things in standard libraries marked obsolete before
> > > removing?
> >
> > With a wrapper, we don't care.
> >
> > > [1] man memalign:
> > > On many systems there are alignment restrictions, for example, on
> > buf-
> > > fers used for direct block device I/O. POSIX specifies the
> > path-
> > > conf(path,_PC_REC_XFER_ALIGN) call that tells what alignment is
> > needed.
> > > Now one can use posix_memalign() to satisfy this requirement.
> > >
> > > posix_memalign() verifies that alignment matches the
> > requirements
> > > detailed above. memalign() may not check that the alignment
> > argument
> > > is correct.
> >
> > Yes, you can get it wrong with memalign. But we don't, because we
> > follow the rules for DIO buffer alignment and set it correctly.
> > Being able to directly control the alignment of the memory buffer is
> > a reason for using memalign() over posix_memalign(), not the other
> > way around.
> >
>
> So a wrapper used on all platforms is an acceptable solution? All right,
> this explanation makes sense. I will change it that way. The only question
> I have now is whether to use posix_memalign on every platform, or whether to
> make it platform_memalign and use the old memalign inside for Linux.
No need for a wrapper on platforms that support memalign. We can add
a wrapper when and if memalign ever goes away (which, FWIW, will
break lots of code). Indeed, we alreadyhave these platform dependent
"wrappers":
include/darwin.h:#define memalign(a,sz) valloc(sz)
include/freebsd.h:#define memalign(a,sz) valloc(sz)
The question now is - do we even need to change anything?
https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man3/valloc.3.html
"The valloc() function allocates size bytes of memory and returns a
pointer to the allocated memory. The allocated memory is
aligned on a page boundary"
Which means it does pretty exactly the same thing as
posix_memalign(), and so we don't need to change anything, right?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign
2015-08-18 22:01 ` Dave Chinner
@ 2015-08-19 8:06 ` Jan Tulak
0 siblings, 0 replies; 42+ messages in thread
From: Jan Tulak @ 2015-08-19 8:06 UTC (permalink / raw)
To: Dave Chinner; +Cc: Christoph Hellwig, xfs-oss
[-- Attachment #1.1: Type: text/plain, Size: 3856 bytes --]
On Wed, Aug 19, 2015 at 12:01 AM, Dave Chinner <david@fromorbit.com> wrote:
> On Tue, Aug 18, 2015 at 10:33:49AM +0200, Jan Tulak wrote:
> > On Tue, Aug 18, 2015 at 10:20 AM, Dave Chinner <david@fromorbit.com>
> wrote:
> >
> > > On Tue, Aug 18, 2015 at 09:04:24AM +0200, Jan Tulak wrote:
> > > > I thought about it. However, with memalign from malloc marked
> obsolete
> > > > (and with posix_memalign having guaranteed alignment restrictions
> [1]), I
> > > > saw it better
> > > > to use the posix variant everywhere.
> > >
> > > Putting a sane wrapper around an nasty library function is just
> > > fine. The memalign wrapper makes sense from this perspective - even
> > > gcc can't tell if variables passed to posix_memalign are correctly
> > > initialised or not, whereas no such problems exist for memalign().
> > >
> > > > I could make a wrapper simulating the old memalign behaviour, but I
> don't
> > > > think it would make sense.
> > >
> > > I think it makes more sense than using posix_memalign() everywhere
> > > and then ignoring the return variable that tells you it failed...
> > >
> > > > I searched for this, but didn't find any reasonable answer:
> > > > How long can be things in standard libraries marked obsolete before
> > > > removing?
> > >
> > > With a wrapper, we don't care.
> > >
> > > > [1] man memalign:
> > > > On many systems there are alignment restrictions, for
> example, on
> > > buf-
> > > > fers used for direct block device I/O. POSIX specifies
> the
> > > path-
> > > > conf(path,_PC_REC_XFER_ALIGN) call that tells what alignment
> is
> > > needed.
> > > > Now one can use posix_memalign() to satisfy this requirement.
> > > >
> > > > posix_memalign() verifies that alignment matches the
> > > requirements
> > > > detailed above. memalign() may not check that the alignment
> > > argument
> > > > is correct.
> > >
> > > Yes, you can get it wrong with memalign. But we don't, because we
> > > follow the rules for DIO buffer alignment and set it correctly.
> > > Being able to directly control the alignment of the memory buffer is
> > > a reason for using memalign() over posix_memalign(), not the other
> > > way around.
> > >
> >
> > So a wrapper used on all platforms is an acceptable solution? All right,
> > this explanation makes sense. I will change it that way. The only
> question
> > I have now is whether to use posix_memalign on every platform, or
> whether to
> > make it platform_memalign and use the old memalign inside for Linux.
>
> No need for a wrapper on platforms that support memalign. We can add
> a wrapper when and if memalign ever goes away (which, FWIW, will
> break lots of code). Indeed, we alreadyhave these platform dependent
> "wrappers":
>
> include/darwin.h:#define memalign(a,sz) valloc(sz)
> include/freebsd.h:#define memalign(a,sz) valloc(sz)
>
> The question now is - do we even need to change anything?
>
>
> https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man3/valloc.3.html
>
> "The valloc() function allocates size bytes of memory and returns a
> pointer to the allocated memory. The allocated memory is
> aligned on a page boundary"
>
> Which means it does pretty exactly the same thing as
> posix_memalign(), and so we don't need to change anything, right?
>
>
Mmm, I'm sure I had some issue with valloc - that was why I decided to
replace it.
But now, I can't remember what exactly it was and everything seems to work
the same
with or without it. :-/
So maybe the real cause of the issue was something else, fixed in another
patch,
making this one abundant...
OK, I'm moving it out of the patchset. And I'm thinking about some private
issue
tracker where I can make notes, reference commits and such. :D
Cheers,
Jan
--
Jan Tulak
jtulak@redhat.com
[-- Attachment #1.2: Type: text/html, Size: 5319 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 09/11] xfsprogs: prevent LIST_ macros conflicts
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
` (7 preceding siblings ...)
2015-08-17 16:23 ` [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 19:36 ` Christoph Hellwig
2015-08-17 16:23 ` [PATCH 10/11] xfsprogs: Update doc for OS X Jan Tulak
` (2 subsequent siblings)
11 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
BSD 4.4 added some LIST_ macros into system header files, which
causes "macro redefined" warnings. To ensure we use our own macros,
undefine the system ones at first.
The conflicting macros are LIST_HEAD and LIST_HEAD_INIT
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
include/list.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/include/list.h b/include/list.h
index 3f087a4..f92faed 100644
--- a/include/list.h
+++ b/include/list.h
@@ -19,6 +19,20 @@
#define __LIST_H__
/*
+ * This undef is here because BSD 4.4 added some LIST_ macros into system
+ * header file sys/queue.h. This header is included in many other system
+ * headers and thus causes "macro redefined" warnings.
+ *
+ * As OS X is kind of a derivate of BSD, this affects OS X too.
+ *
+ * To use our own LIST_ macros (copied from kernel code), we have to
+ * at first undefine the conflicting system macros.
+ *
+ */
+#undef LIST_HEAD
+#undef LIST_HEAD_INIT
+
+/*
* Simple, generic doubly-linked list implementation.
*/
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 10/11] xfsprogs: Update doc for OS X
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
` (8 preceding siblings ...)
2015-08-17 16:23 ` [PATCH 09/11] xfsprogs: prevent LIST_ macros conflicts Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 19:36 ` Christoph Hellwig
2015-08-17 16:23 ` [PATCH 11/11] xfsprogs: Add a way to compile without blkid Jan Tulak
2015-08-17 21:55 ` [PATCH 00/11] xfsprogs: Partial OS X support Dave Chinner
11 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
Update build info and limitations.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
---
doc/INSTALL | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/doc/INSTALL b/doc/INSTALL
index ba3472b..b0443a3 100644
--- a/doc/INSTALL
+++ b/doc/INSTALL
@@ -52,12 +52,16 @@ Mac OS X Instructions
=====================
0. Note: since there is no XFS implementation on Mac OS X, you are
- severely limited in what you can do. mkfs.xfs(8), xfs_db(8) and
+ severely limited in what you can do. mkfs.xfs(8), xfs_db(8) and
xfs_repair(8) are the only functional tools on this platform, as
they do not interact with the XFS kernel code at all. Still, it
can be useful to have access to these utilities from Mac OS X in
a dual boot configuration, for example.
+ However, keep on mind that mkfs.xfs on Mac OS X has disabled
+ device access, although you can create a filesystem in a file.
+ Also note that existing filesystem detection is disabled.
+
1. Configure, build and install the package
The xfsprogs package uses autoconf/configure and expects a GNU build
@@ -65,7 +69,8 @@ Mac OS X Instructions
and glibtool).
You will also need to have built and installed the UUID library which
- is provided by the e2fsprogs source package.
+ is provided by the e2fsprogs source package. (Or use Homebrew, Macports
+ or any other 3rd party package manager.)
Building libuuid:
@@ -84,7 +89,7 @@ Mac OS X Instructions
TAR=/usr/bin/gnutar
LIBTOOL=/usr/bin/glibtool
INSTALL_GROUP=wheel
- LOCAL_CONFIGURE_OPTIONS="--enable-gettext=no"
+ LOCAL_CONFIGURE_OPTIONS="--enable-gettext=no --enable-blkid=no"
$ make
$ su root
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 11/11] xfsprogs: Add a way to compile without blkid
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
` (9 preceding siblings ...)
2015-08-17 16:23 ` [PATCH 10/11] xfsprogs: Update doc for OS X Jan Tulak
@ 2015-08-17 16:23 ` Jan Tulak
2015-08-17 19:39 ` Christoph Hellwig
2015-08-17 21:55 ` [PATCH 00/11] xfsprogs: Partial OS X support Dave Chinner
11 siblings, 1 reply; 42+ messages in thread
From: Jan Tulak @ 2015-08-17 16:23 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
UPDATE: default to "signature found", so without blkid is
-f mandatory.
Because not all platforms have up-to-date blkid with required
functions, allow at least partial functionality by adding
--enable-blkid=yes/no optional configure argument.
When blkid is disabled, signature detection and device geometry
detection doesn't work.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
---
configure.ac | 10 +++++++++-
include/builddefs.in | 1 +
mkfs/xfs_mkfs.c | 22 +++++++++++++++++++++-
3 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index abb7904..eeba20d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,6 +26,11 @@ AC_ARG_ENABLE(gettext,
enable_gettext=yes)
AC_SUBST(enable_gettext)
+AC_ARG_ENABLE(blkid,
+[ --enable-blkid=[yes/no] Enable use of block device id library [default=yes]],,
+ enable_blkid=yes)
+AC_SUBST(enable_blkid)
+
AC_ARG_ENABLE(readline,
[ --enable-readline=[yes/no] Enable readline command editing [default=no]],
test $enable_readline = yes && libreadline="-lreadline",
@@ -117,9 +122,12 @@ AC_HAVE_PREADV
AC_HAVE_SYNC_FILE_RANGE
AC_HAVE_MNTENT
AC_HAVE_FLS
-AC_HAVE_BLKID_TOPO
AC_HAVE_READDIR
+if test "$enable_blkid" = yes; then
+AC_HAVE_BLKID_TOPO
+fi
+
AC_CHECK_SIZEOF([long])
AC_CHECK_SIZEOF([char *])
AC_TYPE_UMODE_T
diff --git a/include/builddefs.in b/include/builddefs.in
index 8851956..f3f8089 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -89,6 +89,7 @@ ENABLE_SHARED = @enable_shared@
ENABLE_GETTEXT = @enable_gettext@
ENABLE_EDITLINE = @enable_editline@
ENABLE_READLINE = @enable_readline@
+ENABLE_BLKID = @enable_blkid@
HAVE_ZIPPED_MANPAGES = @have_zipped_manpages@
diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
index d349b4f..56d2410 100644
--- a/mkfs/xfs_mkfs.c
+++ b/mkfs/xfs_mkfs.c
@@ -18,7 +18,9 @@
#include "libxfs.h"
#include <ctype.h>
-#include <blkid/blkid.h>
+#ifdef ENABLE_BLKID
+# include <blkid/blkid.h>
+#endif /* ENABLE_BLKID */
#include "xfs_mkfs.h"
/*
@@ -298,6 +300,7 @@ calc_stripe_factors(
* 0 for nothing found
* -1 for internal error
*/
+#ifdef ENABLE_BLKID
static int
check_overwrite(
char *device)
@@ -451,6 +454,19 @@ out_free_probe:
_("warning: unable to probe device topology for device %s\n"),
device);
}
+#else /* ifdef ENABLE_BLKID */
+/*
+ * Without blkid, we can't do a good check for signatures.
+ * So instead of some messy attempts, just disable any checks
+ * and always return 'nothing found'.
+ */
+static int
+check_overwrite(
+ char *device)
+{
+ return 1;
+}
+#endif /* ENABLE_BLKID */
static void get_topology(
libxfs_init_t *xi,
@@ -483,16 +499,20 @@ static void get_topology(
} else
ft->psectorsize = ft->lsectorsize = BBSIZE;
} else {
+#ifdef ENABLE_BLKID
blkid_get_topology(dfile, &ft->dsunit, &ft->dswidth,
&ft->lsectorsize, &ft->psectorsize,
force_overwrite);
+#endif /* ENABLE_BLKID */
}
if (xi->rtname && !xi->risfile) {
int sunit, lsectorsize, psectorsize;
+#ifdef ENABLE_BLKID
blkid_get_topology(xi->rtname, &sunit, &ft->rtswidth,
&lsectorsize, &psectorsize, force_overwrite);
+#endif /* ENABLE_BLKID */
}
}
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 11/11] xfsprogs: Add a way to compile without blkid
2015-08-17 16:23 ` [PATCH 11/11] xfsprogs: Add a way to compile without blkid Jan Tulak
@ 2015-08-17 19:39 ` Christoph Hellwig
2015-08-18 7:59 ` Jan Tulak
2015-08-18 12:02 ` [PATCH v2 " Jan Tulak
0 siblings, 2 replies; 42+ messages in thread
From: Christoph Hellwig @ 2015-08-17 19:39 UTC (permalink / raw)
To: Jan Tulak; +Cc: hch, xfs
On Mon, Aug 17, 2015 at 06:23:26PM +0200, Jan Tulak wrote:
> UPDATE: default to "signature found", so without blkid is
> -f mandatory.
Belongs in the cover letter, not this patch.
> } else
> ft->psectorsize = ft->lsectorsize = BBSIZE;
> } else {
> +#ifdef ENABLE_BLKID
> blkid_get_topology(dfile, &ft->dsunit, &ft->dswidth,
> &ft->lsectorsize, &ft->psectorsize,
> force_overwrite);
> +#endif /* ENABLE_BLKID */
> }
>
> if (xi->rtname && !xi->risfile) {
> int sunit, lsectorsize, psectorsize;
>
> +#ifdef ENABLE_BLKID
> blkid_get_topology(xi->rtname, &sunit, &ft->rtswidth,
> &lsectorsize, &psectorsize, force_overwrite);
> +#endif /* ENABLE_BLKID */
I think you need to proide a dummy blkid_get_topology which at least
sets the two sector sizes to 512.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 11/11] xfsprogs: Add a way to compile without blkid
2015-08-17 19:39 ` Christoph Hellwig
@ 2015-08-18 7:59 ` Jan Tulak
2015-08-18 12:02 ` [PATCH v2 " Jan Tulak
1 sibling, 0 replies; 42+ messages in thread
From: Jan Tulak @ 2015-08-18 7:59 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs-oss
[-- Attachment #1.1: Type: text/plain, Size: 1551 bytes --]
On Mon, Aug 17, 2015 at 9:39 PM, Christoph Hellwig <hch@infradead.org>
wrote:
> On Mon, Aug 17, 2015 at 06:23:26PM +0200, Jan Tulak wrote:
> > UPDATE: default to "signature found", so without blkid is
> > -f mandatory.
>
> Belongs in the cover letter, not this patch.
>
I forgot to remove it from the patch, sorry for that.
>
> > } else
> > ft->psectorsize = ft->lsectorsize = BBSIZE;
> > } else {
> > +#ifdef ENABLE_BLKID
> > blkid_get_topology(dfile, &ft->dsunit, &ft->dswidth,
> > &ft->lsectorsize, &ft->psectorsize,
> > force_overwrite);
> > +#endif /* ENABLE_BLKID */
> > }
> >
> > if (xi->rtname && !xi->risfile) {
> > int sunit, lsectorsize, psectorsize;
> >
> > +#ifdef ENABLE_BLKID
> > blkid_get_topology(xi->rtname, &sunit, &ft->rtswidth,
> > &lsectorsize, &psectorsize,
> force_overwrite);
> > +#endif /* ENABLE_BLKID */
>
> I think you need to proide a dummy blkid_get_topology which at least
> sets the two sector sizes to 512.
>
I don't think so. blkid_get_topology is used only for block devices, not
when mkfs-ing a file. And there are multiple further issues with mkfs
on OS X with system calls, so such dummy call would be for no use.
Although, when I think about it, removing few ifdef would certainly make
the code
cleaner, so I think I can make a dummy call for this reason.
Cheers,
Jan
--
Jan Tulak
jtulak@redhat.com
[-- Attachment #1.2: Type: text/html, Size: 2576 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread* [PATCH v2 11/11] xfsprogs: Add a way to compile without blkid
2015-08-17 19:39 ` Christoph Hellwig
2015-08-18 7:59 ` Jan Tulak
@ 2015-08-18 12:02 ` Jan Tulak
1 sibling, 0 replies; 42+ messages in thread
From: Jan Tulak @ 2015-08-18 12:02 UTC (permalink / raw)
To: xfs; +Cc: hch, Jan Tulak
CHANGELOG:
- added #warning message
- use dummy blkid_get_topology instead of #ifdefs
- fix autoconf (wasn't passing -DENABLE_BLKID flag, lost during
patch cleaning.)
Because not all platforms have up-to-date blkid with required
functions, allow at least partial functionality by adding
--enable-blkid=yes/no optional configure argument.
When blkid is disabled, signature detection and device geometry
detection doesn't work.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
---
configure.ac | 10 +++++++++-
include/builddefs.in | 5 +++++
mkfs/xfs_mkfs.c | 37 ++++++++++++++++++++++++++++++++++++-
3 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index abb7904..eeba20d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,6 +26,11 @@ AC_ARG_ENABLE(gettext,
enable_gettext=yes)
AC_SUBST(enable_gettext)
+AC_ARG_ENABLE(blkid,
+[ --enable-blkid=[yes/no] Enable use of block device id library [default=yes]],,
+ enable_blkid=yes)
+AC_SUBST(enable_blkid)
+
AC_ARG_ENABLE(readline,
[ --enable-readline=[yes/no] Enable readline command editing [default=no]],
test $enable_readline = yes && libreadline="-lreadline",
@@ -117,9 +122,12 @@ AC_HAVE_PREADV
AC_HAVE_SYNC_FILE_RANGE
AC_HAVE_MNTENT
AC_HAVE_FLS
-AC_HAVE_BLKID_TOPO
AC_HAVE_READDIR
+if test "$enable_blkid" = yes; then
+AC_HAVE_BLKID_TOPO
+fi
+
AC_CHECK_SIZEOF([long])
AC_CHECK_SIZEOF([char *])
AC_TYPE_UMODE_T
diff --git a/include/builddefs.in b/include/builddefs.in
index 8851956..6c16a65 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -89,6 +89,7 @@ ENABLE_SHARED = @enable_shared@
ENABLE_GETTEXT = @enable_gettext@
ENABLE_EDITLINE = @enable_editline@
ENABLE_READLINE = @enable_readline@
+ENABLE_BLKID = @enable_blkid@
HAVE_ZIPPED_MANPAGES = @have_zipped_manpages@
@@ -138,6 +139,10 @@ endif
ifeq ($(HAVE_MNTENT),yes)
PCFLAGS+= -DHAVE_MNTENT
endif
+ifeq ($(ENABLE_BLKID),yes)
+PCFLAGS+= -DENABLE_BLKID
+endif
+
GCFLAGS = $(OPTIMIZER) $(DEBUG) \
-DVERSION=\"$(PKG_VERSION)\" -DLOCALEDIR=\"$(PKG_LOCALE_DIR)\" \
diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
index d349b4f..e7bbb10 100644
--- a/mkfs/xfs_mkfs.c
+++ b/mkfs/xfs_mkfs.c
@@ -18,7 +18,9 @@
#include "libxfs.h"
#include <ctype.h>
-#include <blkid/blkid.h>
+#ifdef ENABLE_BLKID
+# include <blkid/blkid.h>
+#endif /* ENABLE_BLKID */
#include "xfs_mkfs.h"
/*
@@ -298,6 +300,7 @@ calc_stripe_factors(
* 0 for nothing found
* -1 for internal error
*/
+#ifdef ENABLE_BLKID
static int
check_overwrite(
char *device)
@@ -451,6 +454,38 @@ out_free_probe:
_("warning: unable to probe device topology for device %s\n"),
device);
}
+#else /* ifdef ENABLE_BLKID */
+/*
+ * Without blkid, we can't do a good check for signatures.
+ * So instead of some messy attempts, just disable any checks
+ * and always return 'nothing found'.
+ */
+# warning BLKID is disabled, so signature detection and block device\
+ access are not working!
+static int
+check_overwrite(
+ char *device)
+{
+ return 1;
+}
+
+static void blkid_get_topology(
+ const char *device,
+ int *sunit,
+ int *swidth,
+ int *lsectorsize,
+ int *psectorsize,
+ int force_overwrite)
+{
+ /*
+ * Shouldn't make any difference (no blkid = no block device access),
+ * but make sure this dummy replacement returns with at least some
+ * sanity.
+ */
+ *lsectorsize = *psectorsize = 512;
+}
+
+#endif /* ENABLE_BLKID */
static void get_topology(
libxfs_init_t *xi,
--
2.4.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: [PATCH 00/11] xfsprogs: Partial OS X support
2015-08-17 16:23 [PATCH 00/11] xfsprogs: Partial OS X support Jan Tulak
` (10 preceding siblings ...)
2015-08-17 16:23 ` [PATCH 11/11] xfsprogs: Add a way to compile without blkid Jan Tulak
@ 2015-08-17 21:55 ` Dave Chinner
2015-08-18 9:14 ` Jan Tulak
11 siblings, 1 reply; 42+ messages in thread
From: Dave Chinner @ 2015-08-17 21:55 UTC (permalink / raw)
To: Jan Tulak; +Cc: hch, xfs
On Mon, Aug 17, 2015 at 06:23:15PM +0200, Jan Tulak wrote:
> This is a third iteration of OS X support patches. Notes with information about
> changes in every patch since the last bulk submittation (or at least the last
> iteration of that patch) follows.
What version of the patches are these? I see some patches in
previous thread with "v4" on them, so I don't know whether they are
more recent than these or not.
FWIW, I'm not picking on you; I'm trying to explain what I see and
why it makes it difficult for me to work out what is going on so you
understand why I might be asking for specific information. Nobody
explains this stuff to new developers; you pick it up through trial
an error, and emails like this :/
What I'm seeing in my inbox is threads like this:
patch 0 v1
->patch 1
->patch 2
->patch 3
patch 0 v2
->patch 1 V2
->patch 2 V2
->patch 2 V3
-> patch 2 V4
->patch 3 V2
patch 0 v3
->patch 1 v3
->patch 2 v3
->patch 2 V4
->patch 3 v3
And so you can see how confusing "patch 2 V3" or "patch 2 v4" gets
when they are versioned this way. I don't know which one is most
recent just by looking at the patch subject.
I try to avoid this problem by putting a version on the patchset
itself (i.e. on the patch 0 letter) and then the individual patches
do not have a version. If I update a patch within a series, it gets
a v2, v3, etc on each repost within that overall patch series. When
I repost the entire patch series as a new version, however, I send
the latest version of the patch without a version. i.e. the threads
look like:
patch 0 v1
->patch 1
->patch 2
->patch 3
patch 0 v2 (w/ changelog for v2)
->patch 1
->patch 2
->patch 2 V2 (w/ changelog)
-> patch 2 V3 (w/ changelog)
->patch 3
patch 0 v3 (w/ changelog for v3)
->patch 1
->patch 2
->patch 2 V2 (w/ changelog)
->patch 3
And so the lastest patches are always in the latest thread the
patch series has been posted.
> BTW: for the patches which already got "Reviewed-by", I added the line
> to these patches. If this is not a good thing and I should let the reviewer
> to submit his reviewed-by email again, tell me. :-)
No, that's the rigth thing to do, and you don't need to mention it
in the changelog. Seeing the tag in the commit message tells both
the reviewer and the maintainer that the patchhas already been
reviewed and does not need to be rescrutinised.
Of course, that means if you change the patch you need to remove the
reviewed-by tag to tell reviewers it needs to be looked at again
and the change documented in the change log...
Speaking of change logs:
> undefined variable fix
> - better explanation in commit
>
> Add ifdef dirent checks where it was missing
> - added approximation of d_reclen
> - text width fix
>
> Change OS X-specific CFLAGS/LDFLAGS
> - Nothing, already reviewed
>
> Add includes required for OS X builds
> - updated for libdisk gone
>
> missing and dummy calls for OS X support
> - new patch (no review yet)
>
> Add mntent.h check into autoconf
> - new patch
> - autoconf change
>
> Add fls check into autoconf
> - new patch
> - autoconf change
>
> replace obsolete memalign with posix_memalign
> - new patch
> - remove strange code formatted
>
> prevent LIST_ macros conflicts
> - already reviewed
> - new patch
>
> Update doc for OS X
> - new patch (no review yet)
>
> Add a way to compile without blkid
> - new patch
> - changed default behaviour if BLKID is disabled such that mkfs -f is required
Better is this:
Version 3:
- better commit messages (patch 1)
- formatting fixes (patch 2, 8)
- autoconf updates (patch 6, 7)
- changed default behaviour if BLKID is disabled such that mkfs -f
is required (patch 11)
Version 2:
- added approximation of d_reclen (patch 2)
- updated for libdisk removal (patch 4)
- OS X documentation update (new patch 10)
So we have some idea of what changed between two reposts of the
patch series, and we have some context of the changes that have
previously been asked for during review without having to go back to
the previous threads.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [PATCH 00/11] xfsprogs: Partial OS X support
2015-08-17 21:55 ` [PATCH 00/11] xfsprogs: Partial OS X support Dave Chinner
@ 2015-08-18 9:14 ` Jan Tulak
0 siblings, 0 replies; 42+ messages in thread
From: Jan Tulak @ 2015-08-18 9:14 UTC (permalink / raw)
To: Dave Chinner; +Cc: Christoph Hellwig, xfs-oss
[-- Attachment #1.1: Type: text/plain, Size: 1065 bytes --]
On Mon, Aug 17, 2015 at 11:55 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Mon, Aug 17, 2015 at 06:23:15PM +0200, Jan Tulak wrote:
> > This is a third iteration of OS X support patches. Notes with
> information about
> > changes in every patch since the last bulk submittation (or at least the
> last
> > iteration of that patch) follows.
>
> What version of the patches are these? I see some patches in
> previous thread with "v4" on them, so I don't know whether they are
> more recent than these or not.
>
> FWIW, I'm not picking on you; I'm trying to explain what I see and
> why it makes it difficult for me to work out what is going on so you
> understand why I might be asking for specific information. Nobody
> explains this stuff to new developers; you pick it up through trial
> an error, and emails like this :/
>
Thank you much for this email - without someone providing me a feedback,
I would have just a little hope of getting better. :-)
Next patches should be versioned and changelogged better.
Cheers,
Jan
--
Jan Tulak
jtulak@redhat.com
[-- Attachment #1.2: Type: text/html, Size: 1679 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 42+ messages in thread