Re: [RFC][PATCH 0/6] Enable multiple mounts of devpts

["H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>]

Kyle Moffett wrote:
> On Tue, Aug 5, 2008 at 2:15 AM, Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>> 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.
>> An interesting point.  What should the semantics be.  If we unmount /dev/pts
>> and people still have ptys open.  -EBUSY?  Except for lazy unmounts?
> 
> Well, even if it's unmounted you can still access your pty with
> /dev/tty.  As it stands right now it's possible to "umount /dev/pts"
> from an SSH login and still have a mostly-functional system.

This is only because there is always an instance in the kernel.

> The only
> failure will be when somebody needs a pseudo-TTY and you have devpts
> unmounted and UNIX98 ptys turned off.
> 
> So for the legacy case, the behavior should be exactly as it is now.
> In the CONFIG_DEVPTY_FORCE_PERMOUNT/"permount"-option case, I agree
> that you could easily go either way.

In the multimount case, we should refuse umounts (except, obviously, 
lazy umounts) if there are ptys open, or ptys used as current terminals, 
in that filesystem.  Simple.

	-hpa