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

Cyrill Gorcunov gorcunov at virtuozzo.com
Tue Jul 21 08:35:13 PDT 2015


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).

 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.

 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.

	Cyrill



More information about the Devel mailing list