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

[Vladimir Davydov]

On Thu, Aug 06, 2015 at 01:26:47PM +0300, Cyrill Gorcunov wrote:
> On Thu, Aug 06, 2015 at 12:55:41PM +0300, Vladimir Davydov wrote:

> > Anyway, if it is difficult for criu to work with ioctls, we should
> > probably revise our policy. May be we could move all user API that needs
> > to be called on start/restore to ve cgroup, while leaving as ioctls only
> > those that are only supposed to be called when the container is running
> > (e.g. getting stats). What do you think?
> 
> At the moment we don't use any non-vanilla ioctl and I would really
> prefer to not have to use them (one of the problem -- Pavel is currently
> hosting general criu code on github and if for some reason we would
> start using custom ioctls which would have to be wrapped into a
> plugin in worst case, this would bring code divergence -- instead of
> using simply vanilla criu we would have to ship plugins in addition.
> And testing all this zoo of tools definitely won't add any fun.)

OK, I see.

> 
> Maybe let gather all ioctls we won't be able to escape using into
> one place and check what we can do?

I don't think it's strictly necessary - we can do it in the course of
porting old APIs. We just need to refine our policy:

 - Everything that has to be configured at restore must be moved to the
   ve cgroup right now for the sake of criu.

Then having ve.features, ve.os_release, etc perfectly makes sense. Still
VE_CONFIGURE_OPEN_TTY should be left as an ioctl according to our new
policy.