[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