On Mon, Aug 4, 2008 at 10:07 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > 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.
There definitely needs to be a mount option (and possibly a config option to forcibly enable the mount option). I personally have 5 or 6 different custom scripts that depend on being able to unmount and remount devpts without losing access to the TTYs therein. Eventually I will need to port those over to use "mount --move", but it would be bad to have a random kernel upgrade just break my imaging/cloning system. Cheers, Kyle Moffett _______________________________________________ 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