[RFC][PATCH 7/8]: Auto-create ptmx node when mounting devpts
Serge E. Hallyn
serue at us.ibm.com
Thu Aug 21 14:00:40 PDT 2008
Quoting sukadev at us.ibm.com (sukadev at us.ibm.com):
> H. Peter Anvin [hpa at zytor.com] wrote:
> > sukadev at us.ibm.com wrote:
> >> I had the new ptmx node only in 'multi-mount' mode initially. But if users
> >> want the multi-mount semantics, /dev/ptmx must be a symlink. If its a
> >> symlink,
> >> we break in the single-mount case (which does not have the ptmx node and
> >> we don't support mknod in pts).
> > True, but changing that is still a configuration change (adding newns to
> > the fstab); it's not that much more work to change whatever else needs to
> > change.
> Hmm, so, single and multi-mount don't coexist ? i.e some are multi-mounts
> while others are single-mounts.
> The way I looked at is that even if a distro has not yet updated the
> startup script (fstab), we could use the multi-mount. Maybe a container
> startup script could change /dev/ptmx to symlink and both types of
> mounts can work simultaneously.
Suka, I think you are missing Eric's point.
You're imagining there is a problem because you can't have a file inthe
same /dev be both a device node and a symlink.
Eric is pointing out that you don't need a symlink, because the device
node can be a target for a bind mount. So you can do
mknod /dev/ptmx c 5 2
mount --bind /dev/pts/ptmx /dev/ptmx
with no problems in either namespace.
> Would that be unnecessary ?
> > I personally don't expect a whole lot of back-and-forth; I suspect people
> > will switch from the legacy model to the newns model mostly as part of a
> > distro upgrade.
> >>>> I'm open to being convinced and the
> >>>> other problems with that code are more pressing.
> >> Yes, I will look at the latest in linux-next and the ->driver_data
> >> approach.
> >> But just to confirm, we do want try and keep single-mount semantics.
> > Certainly for several years at least.
> > -hpa
More information about the Containers