[lxc-devel] [PATCH] add console to lxc api

[Stéphane Graber]

On 05/29/2013 01:38 PM, Serge Hallyn wrote:
> Quoting Dwight Engen (dwight.engen at oracle.com):
>> On Wed, 29 May 2013 09:24:40 -0500
>> Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
>>
>>> Quoting Dwight Engen (dwight.engen at 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.engen at oracle.com>
>>>
>>> It looks good and tests fine, so overall
>>>
>>> Acked-by: Serge E. Hallyn <serge.hallyn at 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.

> I bet Stéphane has a better idea :)
> 
> -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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
> 


-- 
Stéphane Graber

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130529/cb754223/attachment.pgp>