RE: [Xen-devel] [PATCH] Console Daemon

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> What I was thinking is having the following layout in the store:
> 
> /domain/<uuid>/console/tty
> /domain/<uuid>/console/limit
> /domain/<uuid>/console/history
> 
> tty is obviously the tty for the domain (if tty doesn't 
> exist, it means someone is connected already)
> 
> limit is the maximum amount of data (in bytes) that will be buffered
> 
> history is the amount of history (in bytes) that will be 
> saved.  When a client reconnects, they will first receive 
> whatever's in the history.
> 
> Does this seem agreeable?

Having 'history' when you reconnect seems a bit over the top -- I'd make
this a 'phase 2' thing.

However, having a parameter which indicates the amount of history that
will be logged to disk might be useful. (whenever the file reaches size
X, throw away the first 20%.)

> >Please can you explain how tty's get allocated.
> >  
> In the current scheme, a tty is allocated for each domain 
> whenever data arrives for the domain or if consoled detects a 
> new domain was created.  
> It currently polls to see if new domains were created every 
> second.  You can avoid the race condition by signalling 
> consoled which will break it out of it's select loop.  Not 
> very pretty but it solves the problem of something like xm create -c.

We definitely need xenstore support for registering watchers for items
that don't exist yet. Having to poll is daft.


Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel