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

[Vladimir Davydov]

On Wed, Aug 05, 2015 at 03:52:41PM +0300, Cyrill Gorcunov wrote:
> On Wed, Aug 05, 2015 at 03:30:48PM +0300, Vladimir Davydov wrote:

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

I talked to Konstantin and Pavel and here goes the current policy
regarding the user API:

 - We rework only those pieces of API that do not currently work and
   cannot be fixed by design (like ve create/enter).

 - Since now each container has unique integer ve.veid, which makes it
   possible to call old ioctls on uuid-named containers, we use ioctls
   for such containers too wherever possible.

 - The idea to move from binary API (ioctl) to text-based (cgroup) does
   sound appealing and may be we will eventually switch to it, but to
   make the new API look good, we need time to design it well, so that
   we wouldn't have to rework it once again in Vz8. So we'd better
   postpone this work until we have enough time.

BTW, I don't like the ve cgroup at all, to tell you the truth. That's
why I personally vote for sticking to ioctls. Its lifetime, start/stop
rules make me think, we should have implemented it as a namespace, not
as a cgroup. I wonder if it would be acceptable from vzctl and criu pov.