put xen console message into syslog but xm dmesg is not affected
PATCH 1/4 put xen console message into syslog but xm dmesg is not affected
[1/4] add read pointer to the xen console ring
xen/drivers/char/console.c +20 -5
@@ -217,19 +217,27 @@ static void putchar_console_ring(int c)static void putchar_console_ring (int c) { conring[CONRING_IDX_MASK (conringp++)] = c; -if ( (conringp - conringc) >CONRING_SIZE ) - conringc = conringp -CONRING_SIZE ; }long read_console_ring (XEN_GUEST_HANDLE (char ) str,u32 *pcount,int clear) {unsigned int idx, len, max, sofar, c;unsigned long flags; +static int conringlogp =0 ; max = *pcount; sofar =0 ; - c = conringc; +if (clear <0 ) { +if ( (conringp - conringlogp) >CONRING_SIZE ) + conringlogp = conringp -CONRING_SIZE ; + c = conringlogp; + }else { +if ( (conringp - conringc) >CONRING_SIZE ) + conringc = conringp -CONRING_SIZE ; + c = conringc; + } +while ( (c != conringp) && (sofar < max) ) { idx =CONRING_IDX_MASK (c);
@@ -244,7 +252,7 @@ long read_console_ring(XEN_GUEST_HANDLE( c += len; } -if ( clear ) +if ( clear >0 ) {spin_lock_irqsave (&console_lock, flags);if ( (conringp - c) >CONRING_SIZE )
@@ -252,7 +260,14 @@ long read_console_ring(XEN_GUEST_HANDLE(else conringc = c;spin_unlock_irqrestore (&console_lock, flags); - } + }else if ( clear <0 ) { +spin_lock_irqsave (&console_lock, flags); +if ( (conringp - c) >CONRING_SIZE ) + conringlogp = conringp -CONRING_SIZE ; +else + conringlogp = c; +spin_unlock_irqrestore (&console_lock, flags); + } *pcount = sofar;return 0 ;
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 3 lines · MINAI Katsuhito
[1/4] add read pointer to the xen console ring
Signed-off-by Katsuhito Minai <[email protected]>
Can you briefly explain the semantics of the modified console interface. I'd rather change the interface cleanly than abuse the 'clear' field -- we've broken dom0_op compatibility since 3.0.2 anyway, so taking the cleaner route is definitely preferable.
-- Keir
Hi Keir
Thanks for your comments.
My modification is a simple reading interface that is independent from the interface of "xc_readconsolering (clear/non-clear)" that xm dmesg uses. It can be used if "clear" argument is a negative value.
However, I also think that the "clear" interface is unnecessary. I think that better solution is one of the following idea:
- modification to have independent read pointer of the buffer for each commands and daemons just like reading usual file. But, this might be difficult for hypervisor.
- modification to give the responsibility of logging of the message to only one daemon. Other commands and daemons must read the logging file never to issue xc_readconsolering().
best regards,
Katsuhito Minai
Quoted 15 lines · Keir Fraser
Quoted 3 lines · MINAI Katsuhito
[1/4] add read pointer to the xen console ring
Signed-off-by Katsuhito Minai <[email protected]>Can you briefly explain the semantics of the modified console interface. I'd rather change the interface cleanly than abuse the 'clear' field -- we've broken
dom0_opcompatibility since 3.0.2 anyway, so taking the cleaner route is definitely preferable.-- Keir
Quoted 5 lines · MINAI Katsuhito
However, I also think that the "clear" interface is unnecessary. I think that better solution is one of the following idea:
- modification to have independent read pointer of the buffer for each commands and daemons just like reading usual file. But, this might be difficult for hypervisor.
Yes, this would be good. The caller could pass a start index and a length. Xen then returns characters from that index, up to length bytes (if available). If the given index is too far behind Xen's producer index, Xen would provide bytes from index position (producer - ring_size). In either case Xen would return index position of first byte returned.
-- Keir
Re: [PATCH] [1/4] put xen console message into syslog butxm dmesg is not affected
Hi keir
Thank you for advice.
I'd like to attempt to change xc_readconsolering() interface.
Please let me confirm the following for my understanding.
- Xen should return the index of the oldest character on the console ring when the index that the caller specified is older than the range of the console ring.
- I think that Xen would return index position of "last" byte returned, not first byte.
Best regards,
Katsuhito Minai
Quoted 17 lines · Keir Fraser
Quoted 5 lines · MINAI Katsuhito
However, I also think that the "clear" interface is unnecessary. I think that better solution is one of the following idea:
- modification to have independent read pointer of the buffer for each commands and daemons just like reading usual file. But, this might be difficult for hypervisor.Yes, this would be good. The caller could pass a start index and a length. Xen then returns characters from that index, up to length bytes (if available). If the given index is too far behind Xen's producer index, Xen would provide bytes from index position (producer -
ring_size). In either case Xen would return index position of first byte returned.-- Keir
Re: [PATCH] [1/4] put xen console message into syslog butxm dmesg is not affected
Quoted 5 lines · MINAI Katsuhito
Please let me confirm the following for my understanding.
- Xen should return the index of the oldest character on the console ring when the index that the caller specified is older than the range of the console ring.
Yes, that is an out-of-range input index gets 'rounded up' to the first in-range index. I think that seems a sensible method for bootstrapping a caller with no knowledge about current ring indexes -- they'd pass zero as input and then get back information about the first valid index. Another way would be to have an input flag or unique input index value that means 'just get me characters from the first valid index'. I somewhat prefer the method I already described though.
Quoted 2 lines
- I think that Xen would return index position of "last" byte returned, not first byte.
Seems less natural to me, but we could do it either way. Clearly first can be computed from last, and vice versa.
Also, keeping the facility to clear the console buffer seems sensible (so that 'xm dmesg' can continue to support the normal Linux dmesg -c option) -- but having a separate clear_console_ring dom0_op for that would be cleaner.
Thanks!
-- Keir