On Sat, Nov 01, 2014 at 06:38:02PM +0000, Al Viro wrote:
> On Sat, Nov 01, 2014 at 11:23:34AM -0700, Eric W.Biederman wrote:
>
> > >From your description I am concerned about using the letter combination nsfs. I once used nsfd, and that was so close to nfsd that Linus got confused, and hilarity ensued. nsfs isn't quite as bad but the abbreviation still seems close enough to nfs that confusion could result.
>
> Well, yes, but... the only non-static object in there with "nsfs" in the
> name is nsfs_init(). As for the filename itself... any better suggestions
> would be welcome, but it doesn't really mess the completion tree.
>
> I've no strong preferences here - we might even move it into kernel/nsproxy.c.
> In the latest variant it's ~160 lines...
BTW, as an immediate followup, definition of struct nameidata can be
taken to fs/namei.c now. nd_get_link/nd_set_link become exported, actual
declaration of struct nameidata goes into fs/namei.c and for everything
outside of fs/namei.c it becomes completely opaque.
TBH, I'm somewhat tempted to do something even more extreme - try to treat
it the way we treat pt_regs. I.e. have a pointer to such sucker in
task_struct (NULL most of the time) and chain the instances. That way
we'd be rid of passing that sucker even to ->follow_link() (and to
nd_{set,get}_link() as well). path_init() would push the sucker to the
top of the chain, path_finish(nd, base) (currently open-coded bunch of
if (nd->root.mnt && !(nd->flags & LOOKUP_ROOT))
path_put(&nd->root);
if (base)
fput(base);
) - remove it from the chain. Not sure if it's worth doing - it's slightly
less boilerplate in ->follow_link() and ->put_link() instances and it _might_
reduce the stack footprint in a bunch of places in fs/namei.c (including the
recursion in there), but it might easily end up increasing it instead...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
