On 17/01/18 09:39, Steven Whitehouse wrote:
On 17/01/18 00:15, Andreas Gruenbacher wrote:
On 4 January 2018 at 17:51, Bob Peterson <[email protected]> wrote:
diff --git a/include/uapi/linux/gfs2_ondisk.h
b/include/uapi/linux/gfs2_ondisk.h
index 09f0920f07e9..7eb73c32272f 100644
--- a/include/uapi/linux/gfs2_ondisk.h
+++ b/include/uapi/linux/gfs2_ondisk.h
@@ -403,7 +403,15 @@ struct gfs2_ea_header {
* Log header structure
*/
-#define GFS2_LOG_HEAD_UNMOUNT 0x00000001 /* log is clean */
+#define GFS2_LOG_HEAD_UNMOUNT 0x00000001 /* log is clean */
+#define GFS2_LOG_HEAD_FLUSH_NORMAL 0x00000002 /* normal log
flush */
+#define GFS2_LOG_HEAD_FLUSH_SYNC 0x00000004 /* Sync log flush */
+#define GFS2_LOG_HEAD_FLUSH_SHUTDOWN 0x00000008 /* Shutdown log
flush */
+#define GFS2_LOG_HEAD_FLUSH_FREEZE 0x00000010 /* Freeze flush */
+#define GFS2_LOG_HEAD_RECOVERY 0x00000020 /* Journal
recovery */
+#define GFS2_LOG_HEAD_USERSPACE 0x80000000 /* Written
by gfs2-utils */
+
+#define LH_V1_SIZE (offsetofend(struct gfs2_log_header, lh_hash))
older user-space packages won't know the offsetofend macro, so they
won't build against these kernel headers anymore. Maybe you want to
open-code that?
I think it's more a case of the uapi kernel headers not defining it at all.
Older user space will not be using the LH_V1_SIZE macro either though,
so I'm not sure that matters?
It shouldn't, although it'd be cleaner to not ship symbols to userspace
that can't be used.
On a related note, I've been thinking of revisiting the idea of having
separate, compatible ondisk types for userspace in gfs2-utils, but I'm
still not convinced that the pros outweigh the cons.
Andy
