On Mon, Oct 13, 2014 at 03:42:28PM -0700, Eric W. Biederman wrote:
> >From looking at your proposed code that doesn't look like it will be
> any more difficult to maintain from the namespace side. So I have no
> objects with moving the code in that direction.
>
> > It's obviously a project for the next cycle and it'll require
> > some cooperation between vfs and userns trees, but not too much of it -
> > all we really need is a never-changed commit embedding that structure into
> > all ...ns and passing _that_ to proc_{alloc,free}_inum() replacements
> > Merged both into vfs.git #for-next and usern one. We can do that right
> > after -rc1. Incidentally, it might make sense to move refcount into that
> > common piece as well, but that's independent from the stuff above.
>
> That sounds like a reasonable direction to go. I think your schedule
> may be a tad optimistic time-wise, if for no other reason that code
> reviews take time, but that plan should work.
OK, interim branch (_completely_ untested, and there's quite a bit of
work remaining) is in vfs.git#nsfs. It will be refactored; moreover,
most of that stuff will move out from fs/proc/namespaces.c - either into
fs/nsfs.c or into kernel/nsproxy.c. And purely VFS followups are not even
touched yet - I know what I want to do, and I think there's no obstacles
left, but that's a separate story. "Filesystem for ns dentries/inodes"
part is done, though (modulo debugging and moving it out of fs/proc).
I wonder if we would be better off not using proc_alloc_inum() there -
it's not hard to do a separate allocator, especially since there's no
requirements re non-intersecting sets of inumbers for procfs and for this.
That's the last part shared with procfs...
Anyway, I'm going down right now (nearly 5am here), so further fun will have
to wait a bit...
--
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
