On Mon, May 07, 2018 at 04:41:59PM +0200, Christoph Hellwig wrote: > On Wed, May 02, 2018 at 09:58:56AM -0700, Darrick J. Wong wrote: > > > I really see no point in doing the wrapper. I'd much rather keep > > > xfs_qm_dqread with a the additional argument, be that a flags value > > > or a bool. For example the same patch with the new xfs_dquot_setup > > > kept as xfs_qm_dqread and everyone calling it with an additional > > > false argument would seem much nicer to me. > > > > I'm trying to avoid having a can_alloc argument for the exported _dqread > > interface because none of the callers outside of xfs_dquot.c set it to > > true. > > That's not really a good reason on its own.. Hm, I talked to Dave on IRC, and after some spelunking we unearthed that the whole point of calling _dqread directly was to obtain an uncached dquot that isn't linked into any lists/radix trees/caches/whatever. That way if we end up doing quotacheck we won't have any dquots in memory that are now garbage. >From that perspective it's not as big of a jump to re-hide dqread and add a _dqget_uncached that has a much better comment justifying why it's there and who uses it... --D > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
