From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3b95631057336a534e3c78528e41c0d1@quanstro.net> From: erik quanstrom Date: Mon, 13 Jul 2009 20:50:01 -0400 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] v9fs question Topicbox-Message-UUID: 1e512ca4-ead5-11e9-9d60-3106f5b1d025 On Mon Jul 13 20:43:21 EDT 2009, newsham@lava.net wrote: > > Could we solve this by making private mounts the default (or only > > allowed) behavior? > > I've wondered if there's enough context information > that the fs driver could "fake" per-process mount points > directly. For example, I mount v9fs on /n. Initially > I have no remote mounts in there, but I have /n/ctl. > I echo "mount 1.2.3.4 foo" to /n/ctl and now I have > /n/foo which is served from 1.2.3.4 for my process, but > other processes dont see /n/foo. I fork a child and it > gets /n/foo, too. In the child I mount another directory > and the changes are seen in both the child and the parent. > I then echo "copyns" to /n/ctl and then perform another > mount and the new mount is visible in the child process but > not the parent process. i believe you've described the speaks-for relationship in plan 9. > > This would of course require that the [linux] kernel filesystem > (probably vfs layer) could distinguish who made a filesystem > request. It might also require some hackery to get the > inheritance on fork working properly (although perhaps some > existing unix mechanism could be reused for this purpose, such > as session and process group stuff). how could the fs record the creat without having the uid/gid? - erik