On Fri, Oct 16, 2009 at 3:49 AM, Hendrik Brueckner
brueck...@linux.vnet.ibm.com wrote:
The states are handled by the hvc_iucv itself:
If the hvc_iucv code has a connection established, terminal or console data
are queued and sent to the peer. If the state is disconnected, terminal and
console
On Thu, Oct 15, 2009 at 02:32:54PM -0500, Scott Wood wrote:
Christian Borntraeger wrote:
About the backends, there are some that spin until the text is
delivered (e.g. virtio) , others can drop (e.g. iucv is a connection
oriented protocol and it will (and has to) drop if there is no
On Fri, Oct 16, 2009 at 03:46:45PM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2009-10-15 at 13:57 -0500, Scott Wood wrote:
I'd say the dropping approach is quite undesirable (significant
potential for output loss unless the buffer is huge), unless there's
simply no way to safely spin.
On Fri, 2009-10-16 at 10:33 -0500, Scott Wood wrote:
On Fri, Oct 16, 2009 at 03:46:45PM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2009-10-15 at 13:57 -0500, Scott Wood wrote:
I'd say the dropping approach is quite undesirable (significant
potential for output loss unless the buffer is
Am Mittwoch 14 Oktober 2009 23:53:46 schrieben Sie:
hvc_console_print() calls the HVC client driver's put_chars() callback
to write some characters to the console. If the callback returns 0, that
indicates that no characters were written (perhaps the output buffer is
full), but
On Thu, Oct 15, 2009 at 01:05:47PM +0200, Christian Borntraeger wrote:
The fact that struct console-write returns void indicates that the console
layer is not interested in errors. We have two policies we can implement:
1. drop console messages if case of congestion but keep the system going
Am Donnerstag 15 Oktober 2009 18:09:06 schrieb Scott Wood:
On Thu, Oct 15, 2009 at 01:05:47PM +0200, Christian Borntraeger wrote:
The fact that struct console-write returns void indicates that the
console layer is not interested in errors. We have two policies we can
implement:
1. drop
Christian Borntraeger wrote:
Hmmm, if we are ok with having both options, we should let the hvc backend
decide if it wants to drain or to discard.
If we just busy loop, it actually does not matter how we let hvc_console
react
on 0, as long as we adopt all backends to use that interface
Christian Borntraeger wrote:
Right. Looking at more drivers it seems that both ways (waiting and dropping)
are used.
Hmmm, if we are ok with having both options, we should let the hvc backend
decide if it wants to drain or to discard.
I'd say the dropping approach is quite undesirable
Am Donnerstag 15 Oktober 2009 20:57:45 schrieb Scott Wood:
Doing it in the backend requires the backend to know whether it's being
called for printk or for user I/O. In the latter case, we don't want to
spin, but rather wait for an IRQ (or poll with a timer if there's no IRQ).
Right. Now you
Christian Borntraeger wrote:
About the backends, there are some that spin until the text is delivered (e.g.
virtio) , others can drop (e.g. iucv is a connection oriented protocol and it
will (and has to) drop if there is no connection).
Sure, dropping due to not having a connection makes
On Thu, 2009-10-15 at 13:57 -0500, Scott Wood wrote:
I'd say the dropping approach is quite undesirable (significant
potential for output loss unless the buffer is huge), unless there's
simply no way to safely spin. Hopefully there are no such backends, but
if there are perhaps we can have
hvc_console_print() calls the HVC client driver's put_chars() callback
to write some characters to the console. If the callback returns 0, that
indicates that no characters were written (perhaps the output buffer is
full), but hvc_console_print() treats that as an error and discards the
rest of
13 matches
Mail list logo
