From: Christoph Hellwig <hch@lst.de>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Christoph Hellwig <hch@lst.de>, xfs@oss.sgi.com
Subject: Re: [PATCH] kill XFS_INOBT_IS_FREE_DISK
Date: Wed, 19 Sep 2007 22:22:40 +0200 [thread overview]
Message-ID: <20070919202239.GA32475@lst.de> (raw)
In-Reply-To: <46F16752.1090702@sandeen.net>
On Wed, Sep 19, 2007 at 01:15:46PM -0500, Eric Sandeen wrote:
> Christoph Hellwig wrote:
> > This macro is unused an all other acros in this family operate on native
> > types, so we most likely won't grow a user either.
>
> Looks good to me... FWIW, here are the currently-unused macros in xfs
> cvs, if I'm massaging it right:
>
> _ACL_ACCESS_EXISTS
> _ACL_GET_ACCESS
> SGI_ACL_DEFAULT_SIZE
will go away with conversion to generic posix acl code.
> ATTR_DONTFOLLOW
> ATTR_TRUST
might go away with conversion to generic xattr code.
> BMBT_USE_64
I have a patch for this one.
> CE_CONT
> current_clear_flags_nested
> FSYNC_INVAL
> FSYNC_NOWAIT
We should probably kill these.
> HAVE_DM_EVENTTYPE_T
> HAVE_DM_RIGHT_T
no idea for these.
> HAVE_SPLICE
Backward compat?
> MODEMASK
> NDPP
kill?
> nested_spinlock
> nested_spinunlock
don't your patches kill these?
> SV_KEYED
> SV_LIFO
> SV_PRIO
> sv_timedwait
> sv_timedwait_sig
> sv_wait_sig
should probably go.
> TRACE0
> TRACE1
> TRACE3
kill?
> VN_ISBLK
> VN_ISCHR
> VN_ISLNK
> VREAD
> VSUID
> VSVTX
> VWRITE
I have a patch to kill all this gunk.
> XFS_AT_ALL
> XFS_AT_SIZE_NOPERM
> XFS_AT_TIMES
I have some patches patch to kill XFS_AT_*
> XFS_DFORK_ASIZE_HOST
> XFS_DFORK_DSIZE_HOST
I have some patches to rework XFS_{C,D,I}FORK*
> XB_GET_OWNER
> xfs_buf_ctob
> XFS_BUF_ISORDERED
> XFS_BUF_ISWRITE
> XFS_BUF_OFFSET
> XFS_BUF_SET_OFFSET
> XFS_BUF_SET_SIZE
> XFS_BUF_UNBUSY
> XFS_BUF_VSEMA
not sure what to do with all the buf stuff.
> XFS_IO_DCXVN
> XFS_IOMAP_WRITE_UNWRITTEN
should be gone with the patches I sent to the list.
> xfs_probe_dmapi
> xfs_probe_ioops
> xfs_probe_quota
these are gone in a patch that I sent to the list already.
> XFS_SBF_NOFLAGS
> XFS_SB_VERSION2_REALFBITS
> XFS_SB_VERSION2_RESERVED1BIT
> XFS_SB_VERSION2_RESERVED4BIT
> XFS_SB_VERSION_ADDDALIGN
> XFS_SB_VERSION_ADDEXTFLGBIT
> XFS_SB_VERSION_ADDSHARED
> XFS_SB_VERSION_SUBEXTFLGBIT
> XFS_SB_VERSION_SUBSHARED
I suspect there are kind expected to be unused.
next prev parent reply other threads:[~2007-09-19 20:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-19 16:12 [PATCH] kill XFS_INOBT_IS_FREE_DISK Christoph Hellwig
2007-09-19 18:15 ` Eric Sandeen
2007-09-19 20:22 ` Christoph Hellwig [this message]
2007-09-19 20:29 ` Eric Sandeen
2007-09-19 20:44 ` nscott
2007-09-29 9:45 ` Christoph Hellwig
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=20070919202239.GA32475@lst.de \
--to=hch@lst.de \
--cc=sandeen@sandeen.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.