[Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for console and terminals

[Cyrill Gorcunov]

On Wed, Aug 05, 2015 at 03:30:48PM +0300, Vladimir Davydov wrote:
> > 
> > At the very first we wanted to move pcs6 code into pcs7 codebase
> > but overall idea, as far as I remember, was to not use any specific
> > code (ie our ioctl interfaces and such) until really needed. Thus
> > in first iterations I didn't use ioctls at all, so any client
> > can be accessing container's console, not only our prctl/vzctl tool.
> > One simply may move client/reader into the VE cgroup and open vtty slave
> > peer to fetch console data. It may be some loggin agent or whatever.
> 
> Moving a process to a VE cgroup just to read its tty... This makes me
> sad :-(

You know, this was the idea initially, try to escape as much custom
code as we can in pcs7 (ie no own ioctls or whatever) which would
allow existing tools to make them easier to work with our kernel.
But maybe I'm wrong by now ;)

> > But instead now we using ioctl to open container's console and
> > I think this is not the best option but let it be.
> 
> Why are you so opposed to ioctls? Why did we start to move every piece
> of our user API we could to ve cgroup in the first place? What's the
> point in substituting one private (not mainstream) API with another? Why
> couldn't we left ve.iptables_mask, ve.features, ve.os_release, etc, etc
> as ioctls? We wouldn't have to rewrite libvzctl as much as we have done
> then. It's not a question solely to you. Everybody's done that (me too
> :-), but may be there is a reason I don't know. If you know why ioctls
> suck and ve cgroup rules, I'd really appreciate if you shared.

As to me ioctls on its own are not bad at all, but having some
native interface (such as we do with ve.X entries in cgroups)
make it open for scripting at least: any new feature is a way
easier to test directly from bash without writting some
implementation in vzctl. To be fair the first argument I've
heard of was like "we're moving to cgroups interface. period." ;)

> : static struct tty_struct *vtty_lookup(struct tty_driver *driver,
> : 				      struct inode *inode, int idx)
> : {
> : 	struct tty_struct *tty;
> : 	struct ve_struct *ve = get_exec_env();
> : 
> : 	BUG_ON(driver != vtty_driver);
> 
>         ^^^^^^
> this
> 
> : static int vtty_install(struct tty_driver *driver, struct tty_struct *tty)
> : {
> : 	struct tty_struct *o_tty;
> : 	int idx = tty->index;
> : 	struct ve_struct *ve = get_exec_env();
> : 
> : 	BUG_ON(driver != vtty_driver);
>         ^^^^^^
> 
> and this make code easier IMO. You have to (and do) handle both master
> and slave cases here.

Ah, this one. I see. OK.

> > > 
> > > Sorry, but it is not straight, it is screwed up IMO. If we used Unix98
> > > ptys (which is what we would do if we were not so lazy), we would have
> > > pty slave open by a container (/dev/console) and the master open and
> > > read/flushed by a dispatcher thread. This is how it works in LXC AFAIK.
> > > Now, we don't want to patch the dispatcher, so we want to make the
> > > master throw out data automatically if it is not open.
> > 
> > I was about to write a long description why I think it's not
> > that good, but I see what you mean. Letme try to reverse the
> > approach and implement pcs6 1:1 behaviour with as much pcs6
> > code fetched as I could (I already tried but didn't success
> > can't remember which exactly problems I met).
> 
> It'd be great *IMO*, but I might be wrong, you know. Unfortunately
> nobody except two of us seem to care about this :-(

No, you're right. After this iterations I know now where to keep
private vtty data, map and such. Let me try one more attempt
to convert old code, if it indeed won't suit us then we always
can step back to my former version. After all this is a temporary
solution until we implement emulation via unix98 which I hope
won't stuck in plans forever ;)

> > 
> > Sole cleanup patches on its own are not welcome
> > and you know this.
> 
> Yeah, I occasionally act as a fat troll, sorry :-) If you do feel a
> strong affection to this macro, then please rename it to
> VTTY_DRIVER_ALLOC_FLAGS, so that it won't occasionally conflict with
> something tty-related.

Nothing to worry about :) Sure I can write multiline version and I do.