[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