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

[Cyrill Gorcunov]

On Tue, Jul 21, 2015 at 07:17:19PM +0300, Vladimir Davydov wrote:
> > 
> > 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?

This won't help. The char regions are global, so we have to request
a new region.

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

Yes. Current model is horrible (if you have a few containers, each
gonna be listed inside /proc/tty/drivers instead of single instance
;)

I see what you mean and I completely agree, but this require
rework of driver virtualization model which I definitely won't
achieve in a couple of days.

That said -- lets postprone this task until Beta2,
I've had in planes to rework the model, but simply
had no explicit task assigned.

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

I see.

	Cyrill