Xen devel - Jul 2006 - [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

Signed-off-by: Katsuhito Minai <minai@jp.fujitsu.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 7 Jul 2006, at 09:17, MINAI Katsuhito wrote:
> [1/4] add read pointer to the xen console ring
>
> Signed-off-by: Katsuhito Minai <minai@jp.fujitsu.com>
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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

On 2006年  7月月 11日 (火) 12:00 am, Keir Fraser said:
>
> On 7 Jul 2006, at 09:17, MINAI Katsuhito wrote:
>
>> [1/4] add read pointer to the xen console ring
>>
>> Signed-off-by: Katsuhito Minai <minai@jp.fujitsu.com>
>
> 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
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 11 Jul 2006, at 02:28, MINAI Katsuhito wrote:
> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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


On 11 Jul 2006, at 03:42 pm, Keir Fraser said:
>
> On 11 Jul 2006, at 02:28, MINAI Katsuhito wrote:
>
>> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 11 Jul 2006, at 09:34, MINAI Katsuhito wrote:
> 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.
> - 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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel