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

[Vladimir Davydov]

On Tue, Jul 21, 2015 at 06:35:13PM +0300, Cyrill Gorcunov wrote:
> On Tue, Jul 21, 2015 at 06:18:00PM +0300, Vladimir Davydov wrote:
> > > -#define VZ_VT_MAX_DEVS		12
> > > -	struct tty_driver	*vz_vt_driver;
> > > -	struct tty_struct	*vz_tty_vt[VZ_VT_MAX_DEVS];
> > > -
> > > -	struct tty_struct	*vz_tty_conm;
> > > -	struct tty_struct	*vz_tty_cons;
> > > +#ifdef CONFIG_TTY
> > > +	struct tty_driver	*vtm_driver;
> > > +	struct tty_driver	*vts_driver;
> > > +	struct mutex		vt_mutex;
> > > +#endif
> > 
> > I wonder if we could implement this feature without per-VE tty_driver.
> > Do you think it's possible?
> 
> Well, there are a number of problems raises
> 
>  1) We need own mapping for char device numbers with predefined names
>     (so they won't conflict with existing devices and their names would
>      allow userspace programs to connect to slave peers).

Put it to ve_struct?

> 
>  2) The terminals must be able to zap incoming data, ie write into
>     such terminal won't block the system (here we simply start dropping
>     data if noone reads it). We could try to tune pty code but it has very
>     different logic -- only one master peer can be opened (in contrast
>     to /dev/console or /dev/tty) so we will have to workaraund this
>     somehow which again would lead into a mess.

I don't mean avoiding creating a tty_driver at all. I mean using the
same system-wide vtty tty_driver, which would do all the virtualization
internally, like it is implemented in PCS6.

The reason I ask is that I really don't like TTY_DRIVER_CONTAINERIZED
crap and would prefer to drop it altogether.

> 
>  3) Actually native VT code is somehow close to what we need but it's
>     not virtualized either, so if we want to re-use vt code instead
>     we will have to virtualize it, and this gonna be mess, I tried :/
> 
> That's why I moved all the code into small separate module. If you
> have some ideas -- please share, maybe we indeed find some other way
> (any idea!).
> 
> P.S.:
> To be fair I would love to drop of this feature completely ;) Usually
> containers are connected and operated via traditional unix98 terminals
> so I still wonder who need this feature. At moment there are a few
> records systemd's init sends to /dev/console and centos6 based
> terminals runs "login" on them but again I think we could simply
> forget about this and provide a way more simplier stubs as I posted
> earlier.

This is required for VNC access to container, which I don't think we can
drop. We could and should have implemented this in userspace though, but
now it's too late I'm afraid.