Quoting Stéphane Graber (stgra...@stgraber.org):
> On 05/29/2013 01:38 PM, Serge Hallyn wrote:
> > Quoting Dwight Engen (dwight.en...@oracle.com):
> >> On Wed, 29 May 2013 09:24:40 -0500
> >> Serge Hallyn <serge.hal...@ubuntu.com> wrote:
> >>
> >>> Quoting Dwight Engen (dwight.en...@oracle.com):
> >>>> Make lxc_cmd_console() return the fd from the socket connection to
> >>>> the caller. This fd keeps the tty slot allocated until the caller
> >>>> closes it. Returning the fd allows for a long lived process to
> >>>> close the fd and reuse consoles.
> >>>>
> >>>> Add API function for console allocation.
> >>>>
> >>>> Create test program for console API.
> >>>>
> >>>> Signed-off-by: Dwight Engen <dwight.en...@oracle.com>
> >>>
> >>> It looks good and tests fine, so overall
> >>>
> >>> Acked-by: Serge E. Hallyn <serge.hal...@ubuntu.com>
> >>>
> >>> However, do you think it would be better to call this function
> >>> lxcapi_console_getfd(), and have lxcapi_console() be a higher
> >>> level function which actually runs the lxc_mainloop() the
> >>> way lxc_console() does, either binding to the caller's fds
> >>> 0,1,2, or to 3 passed-in fds?
> >>
> >> Yeah, APIizing this has some questions:
> >>
> >> There currently isn't an lxc_console() that I can see despite there
> >> being a prototype in lxc.h :) Do you mean that lxcapi_console()
> >> essentially be the guts of what is now lxc_console.c? Including setup of
> >> tios, sigwinch handler and mainloop callbacks? I'm fine with doing that
> >> just want to be sure I know what you mean :)
> >
> > That would be my thought.
> >
> >> I think essentially this would mean moving those things from
> >> lxc_console.c to console.c. Doing this would make it easy to write your
> >> own lxc-console with only one call, but I'm not sure how useful that is
> >> without being able to override parts (ie. supply your own mainloop
> >> callbacks for instance). How are people going to want to use/bind to
> >> this functionality?
> >
> > I'm not sure how real people would use this. For me it would just be
> >
> > sudo python3
> > import lxc
> > c=lxc.Container('dir1', None)
> > c.console()
>
> That'll definitely be the default behaviour of the binding with a tty
> parameter letting you choose to attach to console or ttyX.
>
> > or going to purely do-what-i-mean code:
> > x = vte.Terminal()
> > c.console(x.stdin, x.stdout, x.stderr)
>
> I'm a bit less clear about how I'll implement that one. It's likely to
> be a separate function, probably open_console() to be consistent with
> some other python function naming but for the rest, I indeed expect it
> to take the tty and the 3 default fds as arguments.
Heh, good point. It would actually want to just use c.console_getfd()
and pass that fd to the vte terminal, I'd guess...
-serge
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
