Hi all,
I am attaching a patch that adds a new command line option to xenconsoled:

-o, --overflow-data=discard|keep

this option changes the behaviour when dealing with data that overflow
the max capacity of the buffer.
If overflow-data is set to discard (the default), the current behaviour
is used: we discard some data in the middle of the buffer.
If overflow-data is set to keep, we stop listening to the ring until we
free some space in the buffer.
This can cause the ring to fill up and the guest kernel internal buffer
to fill up as well. When this happens the guest kernel stops reading
characters from the console device so the application generating data
hangs. When xenconsoled resumes reading from the ring, the guest kernel
will be able to resume reading from the console device as well. At that
point the guest application will be allowed to continue.

Regards,

Stefano Stabellini

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Keir Fraser wrote:
> On 14/4/08 15:14, "Samuel Thibault" <samuel.thibault@eu.citrix.com> wrote:
> 
>> Keir Fraser, le Fri 11 Apr 2008 16:46:48 +0100, a écrit :
>>> The 'application' in this case is the kernel.
>> Mmm, in my understanding of printk, it is not blocking for the kernel,
>> and if a console is not able to catch up, the data simply gets
>> discarded (see __call_console_drivers, which doesn't check the result
>> of con->write(), which can hence be even 0 if the console is really
>> completely stuck).
> 
> Actually I was worried that we might depend on the ring being drained in a
> timely fashion in our own console driver implementation in Linux. Actually I
> think we don't (except that the handling of x_char looks suspect). Still, I
> don't know whether other guest types depend on the current behaviour. We
> could make the behaviour switchable I suppose.
> 
>  -- Keir
> 
>