Re: [PATCH 11/11][v3]: Enable multiple instances of devpts

[sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org]

H. Peter Anvin [hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org] wrote:
> sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org wrote:
>> But that node will not be accessible if there is a newinstance mount
>> without the bind mount ? IOW
>> 	1. mount -t devpts -o newinstance lxcpts /dev/pts
>> 	2. mount -o bind /dev/pts/ptmx /dev/ptmx
>> If both #1 and #2 or neither happen there is no problem.
>> If #1 is NOT followed by #2, ptys break in new namespace.
>> An open of /dev/ptmx in this case will allocate a pty in the
>> initial namespace, but since #1 is complete, we lookup the
>> pty (/dev/pts/7) in the new namespace and fail.
>
> That is correct.

So afaics, we don't have any issues when operating only in one mode
(single-instance or multi-instance).

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 ?

Or are there other options ?

Thanks,

Suka