| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH] Console Daemon
> 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
|
|
|
| |
|
Home