[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140307023828.GG9875@birch.djwong.org>
Date: Thu, 6 Mar 2014 18:38:28 -0800
From: "Darrick J. Wong" <darrick.wong@...cle.com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: Robert Yang <liezhi.yang@...driver.com>, dvhart@...ux.intel.com,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH V4 05/11] misc/create_inode.c: copy regular file
On Thu, Mar 06, 2014 at 05:57:14PM -0500, Theodore Ts'o wrote:
> On Thu, Mar 06, 2014 at 12:14:39PM -0800, Darrick J. Wong wrote:
> >
> > I'm already queuing up a bunch of (more) fixes... there's more weird things I
> > didn't notice. Such as, why is current_fs now defined in current_inode.h?
> > That really ought to have stayed in debugfs.c, and current_inode.h should have
> > 'extern ext2_filsys current_fs;', no?
>
> Yes, that would be better --- although in the long term we should
> probably try to get rid of the global variable and pass in an "fs"
> parameter into functions in misc/create_inode.c.
Agreed (and fixed).
> Since these aren't in a shared library, I wasn't worried that much
> about the details of the abstraction interface, but I'm sure there are
> some ways that we can improve things.
>
> BTW, one of my plans for 1.43 is to rename libquota.a to libe2int.a,
> and to move things like profile.c, and other files shared between misc
> and e2fsck, etc., into an "internal support" library. I suspect
> create_inoode.c would be a candidate for moving into this internal
> support library.
Higher level functionality? I'd been musing that such a thing might be
beneficial to userland tools.
>
> Cheers,
>
> > ...I'll also respin the patchset I sent out a few days ago.
>
> Sorry for having you respin the patchset yet again --- although
> hopefully it should be easier this time around. I'm trying to be fair
> in catching up with th e2fsprogs backlog, and Robert and Zheng's
> patches have been outstanding for a long time. Don't worry, yours are
> next on the list. :-)
It's fine, (st)git merging isn't usually that painful. I was more worried
about the impact of spamming linux-ext4 with giant patchsets, but respinning is
better than nothing happening at all. :)
That said, combing through all the "new arrivals" when I run the static
checkers ... was intense this time.
Though, it is a little time consuming to run checkpatch, then sparse/cppcheck,
then make check, then the metadata checksum test, and then xfstests. But,
skipping tests isn't acceptable either, given the things I've fubar'd in the
past from /not/ doing that. :)
--D
>
> Cheers,
>
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists