From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/5] xfs: struct xfs_sb is no longer tied to the on-disk format
Date: Tue, 3 Feb 2015 06:30:21 +1100 [thread overview]
Message-ID: <20150202193020.GJ6282@dastard> (raw)
In-Reply-To: <20150202084102.GA28121@infradead.org>
On Mon, Feb 02, 2015 at 12:41:02AM -0800, Christoph Hellwig wrote:
> > /*
> > - * Superblock - in core version. Must match the ondisk version below.
> > - * Must be padded to 64 bit alignment.
> > - */
> > -typedef struct xfs_sb {
> > - __uint32_t sb_magicnum; /* magic number == XFS_SB_MAGIC */
> > - __uint32_t sb_blocksize; /* logical block size, bytes */
>
> > -static inline int xfs_sb_version_hasfinobt(xfs_sb_t *sbp)
> > +static inline int xfs_sb_version_hasfinobt(struct xfs_sb *sbp)
>
> So xfs_format.h now requires struct xfs_sb to be defined before it
> can be included? I guess we need to move these macros around as well.
Yes, that's why I moved it to xfs_super.h, which is included from
xfs_linux.h. I just wanted to move it from xfs_format.h to
/somewhere/ to demonstrate that it isn't part of the on-disk format
anymore.
> > diff --git a/fs/xfs/xfs_super.h b/fs/xfs/xfs_super.h
> > index 2b830c2..a02236b 100644
> > --- a/fs/xfs/xfs_super.h
> > +++ b/fs/xfs/xfs_super.h
> > @@ -61,6 +61,87 @@ struct xfs_mount;
> > struct xfs_buftarg;
> > struct block_device;
> >
> > +/*
> > + * Superblock - in core version. This does not have ot match the size and shape
> > + * of the on-disk superblock, but must contain all the fields that we use in the
> > + * on-disk superblock.
> > + */
> > +struct xfs_sb {
>
> Is this really the right header? xfs_super.h only really is for bits
> related to linux super block operastions.
No, probably not, but it was expedient and good enough for an RFC
and sanity testing. I thought about xfs_mount.h, but then realised
that just introduces a new dependency between xfs_mount.h and
libxfs, which is something I'm trying to reduce.
> I'd expect to move it close to stuct xfs_mount, and maybe even merge
> it into that in the long run.
I guess moving the structure there is fine, but we still want all
the version functions to be shared with userspace, which then makes
for an interesting set of dependencies. Any other ideas?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-02-02 19:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-01 21:42 [RFC PATCH 0/5] xfs: use generic percpu counters for icsb Dave Chinner
2015-02-01 21:42 ` [PATCH 1/5] xfs: struct xfs_sb is no longer tied to the on-disk format Dave Chinner
2015-02-02 8:41 ` Christoph Hellwig
2015-02-02 19:30 ` Dave Chinner [this message]
2015-02-03 21:37 ` Christoph Hellwig
2015-02-03 21:46 ` Dave Chinner
2015-02-03 23:34 ` Dave Chinner
2015-02-01 21:43 ` [PATCH 2/5] xfs: use generic percpu counters for inode counter Dave Chinner
2015-02-02 16:44 ` Christoph Hellwig
2015-02-02 19:33 ` Dave Chinner
2015-02-03 21:38 ` Christoph Hellwig
2015-02-01 21:43 ` [PATCH 3/5] xfs: use generic percpu counters for free " Dave Chinner
2015-02-02 17:10 ` Brian Foster
2015-02-01 21:43 ` [PATCH 4/5] xfs: use generic percpu counters for free block counter Dave Chinner
2015-02-02 16:48 ` Christoph Hellwig
2015-02-02 19:34 ` Dave Chinner
2015-02-02 17:11 ` Brian Foster
2015-02-02 19:39 ` Dave Chinner
2015-02-01 21:43 ` [PATCH 5/5] xfs: Remove icsb infrastructure Dave Chinner
2015-02-02 17:11 ` Brian Foster
2015-02-03 21:50 ` [RFC PATCH 0/5] xfs: use generic percpu counters for icsb Christoph Hellwig
2015-02-03 21:58 ` Dave Chinner
2015-02-03 22:02 ` Christoph Hellwig
2015-02-03 22:13 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150202193020.GJ6282@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox