Skip to contentSkip to conversation

put xen console message into syslog but xm dmesg is not affected

PATCH In review MINAI Katsuhito 2 participants 6 messages Jul 7, 2006 – Jul 11, 2006

lore
Share & tools
lore
#0 lore raw

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
diff -r 8e55c5c11475 xen/drivers/char/console.c
@@ -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

#1 lore raw
Quoted 3 lines · MINAI Katsuhito

[1/4] add read pointer to the xen console ring

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

#2 lore raw

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

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

#3 lore raw
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

#4 lore raw

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

#5 lore raw

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