[EMAIL PROTECTED] wrote: > > When both modes are used simultaneously, we have following options: > > 1. Let container-startup deal with it i.e use above bind-mount approach > or, as Serge mentioned, have containers chroot and make ptmx->pts/ptmx > symlink or another option ? > > 2. Have the ptmx-node even in the initial mount and a "permanent" ptmx > symlink - Did we fully rule it out :-) > > 3. Choose #2 with a (yet-another) config token. Not sure if it adds > value or further complicates the matrix. > > Both #1 and #2 have their pros/cons. Long term, one advantage I see with #2 > is that we don't force container-scripts do something now that they can/should > potentially undo later if we ever want to remove the single-instance > semantics. > > Does presence of /dev/pts/ptmx in single-instance case break userspace ? > If it only surprises, will adding notes to pts(4) man page help ? >
Well, userspaces which implement the #2 option should add the newinstance mount option to ALL mounts of devpts, including the first one. That way the "default" pts instance is never actually exposed. Container scripts which need to work in both modes can trivially determine if they need to do the bind-mount, simply by seeing if /dev/ptmx is already a symlink. -hpa _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel