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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
