[Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for virtual consoles

Cyrill Gorcunov gorcunov at virtuozzo.com
Fri Jul 31 06:20:21 PDT 2015


On Fri, Jul 31, 2015 at 03:24:40PM +0300, Vladimir Davydov wrote:
> 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.

I see. OK, letme try, will send the result.



More information about the Devel mailing list