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

[Cyrill Gorcunov]

On Thu, Aug 06, 2015 at 12:30:46PM +0300, Vladimir Davydov wrote:
> > 
> > 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.

Thanks for summarizing all the bullets! You know I forgot to mention
that cgroups actually saves us a little in criu, because for example,
imagine we need to configure some resource via our non-general ioctl
code -- this require either plugin in criu, either some custom scripting,
which is not convenient.

Could you please share more details on the one before last sentence, I
mean about namespaces.

	Cyrill