[Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for virtual consoles
Vladimir Davydov
vdavydov at parallels.com
Fri Jul 31 05:24:40 PDT 2015
On Fri, Jul 31, 2015 at 02:57:36PM +0300, Cyrill Gorcunov wrote:
> On Fri, Jul 31, 2015 at 01:53:19PM +0300, Vladimir Davydov wrote:
> > >
> > > The distinguishing between VEs is happening on "opener" context,
> > > ie join to VE cgroup, and open /dev/vztm1 the kernel calls
> > > for get_exec_env and allocates appropriate vzt pair.
> >
> > i.e. if I want to open a container's console as a slave I have to put
> > myself into its ve cgroup first?
>
> Exactly. On open the kernel will find that the global character
> device associated with
> tty_fops
> tty_open
> tty_lookup_driver -> vtty_slave
> tty_driver_lookup_tty -> get_exec_env -> map for tty -> lookup for tty in array
>
I really don't like it. You know why? Because if I were a VNC client,
I'd do my best to avoid dealing with the ve cgroup :-) Seriously, you
won't even be able to get out of it once you are done - you're doomed to
die and be buried there :-)
Let's instead introduce an ioctl for it. To be more exact, let's port
VE_CONFIGURE_OPEN_TTY from PCS6. What do you think about it?
My point is that it's a legacy thing which will hopefully pass away in
Vz8, because the whole vtty thing can be perfectly done from userspace
using ptys - you only need a daemon flushing dummy slaves. So using
ioctls for it should be OK.
More information about the Devel
mailing list