[EMAIL PROTECTED] wrote:
>
> Ok. But was wondering if we can pass the ptmx symlink burden to the
> 'container-startup sripts' since they are the ones that need the second
> or subsequent mount of devpts.
>
> So, initially and for systems that don't need multiple mounts of devpts,
> existing behavior can continue (/dev/ptmx is a node).
>
> Container startup scripts have to anyway remount /dev/pts and mknod
> /dev/pts/ptmx. These scripts could additionally check if /dev/ptmx is
> a node and make it a symlink. The container script would have to do
> this check while it still has access to the first mount of devpts
> and mknod in the first devpts mnt.
>
> But then again, the first mount is still special in the kernel.
>
You're right, I think we can do this and still retain most of the
advantages, at least for a transition period.
The idea would be that you'd have a mount option, that if you do not
specify it, you get a bind to the in-kernel mount; otherwise you get a
new instance. ptmx, if not invoked from inside a devpts filesystem,
would default to the kernel-mounted instance.
Unfortunately I believe that means parsing the command options in
getpts_get_sb() to know if we do have the "multi" option, but that isn't
really all that difficult; it just means breaking the parser out as a
separate subroutine.
-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
