On Thu, Jan 17, 2019 at 06:21:26AM -0800, Christoph Hellwig wrote:
> On Mon, Dec 31, 2018 at 06:19:32PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> >
> > Instead of open-coding new inode parameters through xfs_dir_ialloc and
> > xfs_Ialloc, put everything into a structure and pass that instead. This
> > will make it easier to share code with xfsprogs while maintaining the
> > ability for xfsprogs to supply extra new inode parameters.
>
> I find these ad-hoc arg structures rather cumberssome to be honest.
>
> > +/* Initial ids, link count, device number, and mode of a new inode. */
> > +struct xfs_ialloc_args {
> > + struct xfs_inode *pip; /* parent inode or null */
> > +
> > + uint32_t uid;
> > + uint32_t gid;
> > + prid_t prid;
> > +
> > + xfs_nlink_t nlink;
> > + dev_t rdev;
> > +
> > + umode_t mode;
>
> And except for the parent inode this is a significant subsystet of
> stat data. Can't we just pass a struct kstat, and a mask of attributes
> from the kstat we want to set instead? That is use a calling convention
> similar to ->setattr?
We could, but we still want to be able to pass in the parent inode and
the initial project id, so we still need struct xfs_ialloc_args. Using
struct kstat instead of just picking up the fields xfs cares about will
waste stack space for things we're /never/ going to need, like blksize,
attributes* ino, dev, size, btime, and blocks. That also requires us to
maintain enough of a port of struct kstat to userspace in order to share
uid, gid, nlink, rdev, and mode.
I don't think it's worth the trouble, but I want Eric's input before I
go doing things that have repercussions for xfsprogs. :)
--D
