Quoting sukadev@xxxxxxxxxx (sukadev@xxxxxxxxxx): > Serge E. Hallyn [serue@xxxxxxxxxx] wrote: > | Quoting Serge E. Hallyn (serue@xxxxxxxxxx): > | > Quoting sukadev@xxxxxxxxxx (sukadev@xxxxxxxxxx): > | > > > | > > From: Sukadev Bhattiprolu <sukadev@xxxxxxxxxx> > | > > Subject: [PATCH 5/7]: Determine pts_ns from a pty's inode. > | > > > | > > The devpts interfaces currently operate on a specific pts namespace > | > > which they get from the 'current' task. > | > > > | > > With implementation of containers and cloning of PTS namespaces, we want > | > > to be able to access PTYs in a child-pts-ns from a parent-pts-ns. For > | > > instance we could bind-mount and pivot-root the child container on > | > > '/vserver/vserver1' and then access the "pts/0" of 'vserver1' using > | > > > | > > $ echo foo > /vserver/vserver1/dev/pts/0 > | > > > | > > The task doing the above 'echo' could be in parent-pts-ns. So we find > | > > the 'pts-ns' of the above file from the inode representing the above > | > > file rather than from the 'current' task. > | > > > | > > Note that we need to find and hold a reference to the pts_ns to prevent > | > > the pts_ns from being freed while it is being accessed from 'outside'. > | > > > | > > This patch implements, 'pts_ns_from_inode()' which returns the pts_ns > | > > using 'inode->i_sb->s_fs_info'. > | > > > | > > Since, the 'inode' information is not visible inside devpts code itself, > | > > this patch modifies the tty driver code to determine the pts_ns and passes > | > > it into devpts. > | > > > | > > TODO: > | > > What is the expected behavior when '/dev/tty' or '/dev/ptmx' are > | > > accessed from parent-pts-ns. i.e: > | > > > | > > $ echo "foobar" > /vserver/vserver1/dev/tty) > | > > > | > > This patch currently ignores the '/vserver/vserver1' part (that > | > > | > The way this is phrased it almost sounds like you're considering using > | > the pathnames to figure out the ptsns to use :). > | > > | > It's not clear to me what is the sane thing to do. > | > > | > what you're doing here - have /dev/ptmx and /dev/tty always use > | > current->'s ptsns - isn't ideal. > | > > | > It would be nicer to not have a 'devpts ns', and instead have a > | > full device namespace. However, then it still isn't clear how to tie > | > /vs/vs1/dev/ptmx to vs1's device namespace, since there is no device > | > fs to which to tie the devns. > | > > | > We could tie the devns to a device inode on mknod, using the devns of > | > the creating task. Then when starting up vs1, you just have to always > | > let vs1 create /dev/ptmx and /dev/tty. I can't think of anything > | > better offhand. > | > > | > Other ideas? > | > | I suppose you could just create /dev/pts/ptmx and /dev/pts/tty. > | Recommend that in containers /dev/ptmx and /dev/tty be symlinks > | into /dev/pts. Applications don't need to change. If > | ptmx_open() sees that inode->i_sb is a devptsfs, it gets the > | namespace from the sb. If not, then it was a device in /dev > | and it gets the nmespace from current. > > But we would still depend on user-space remounting /dev/pts after > the clone right ? Until they do that we would access the parent > container's /dev/pts/ptmx ? Yes. Which is the right thing to do imo. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers