All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Hongyang <yanghy@cn.fujitsu.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH]xl: Some small fixes to xl
Date: Wed, 26 May 2010 09:02:55 +0800	[thread overview]
Message-ID: <4BFC733F.3010704@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1005241011580.25605@kaball-desktop>

On 05/24/2010 05:16 PM, Stefano Stabellini wrote:
> On Mon, 24 May 2010, Yang Hongyang wrote:
>> Hi jeremy,
>>
>> Thank you for your review.
>>
>> On 05/22/2010 03:25 AM, Jeremy Fitzhardinge wrote:
>>> On 05/21/2010 12:01 AM, Yang Hongyang wrote:
>>>> The patch fixes following problems:
>>>> -When use mem-set, I got suspicious error output:
>>>>  # xl mem-set 1 256g
>>>>  setting domid 1 memory to : 268435456
>>>>  [0] libxl.c:2535:libxl_set_memory_target: memory_dynamic_max must be less than or equal to memory_static_max
>>>>  : Success
>>>> -parse_mem_size_kb() returns type int64_t
>>>> -String generated by strdup() should be freed
>>>> -When using 'xl help', mem-max and mem-set's output is not as intend, and it's also
>>>>  breaks bash completion, fix it.
>>>>
>>>> diff -r 840f269d95fb tools/libxl/libxl.c
>>>> --- a/tools/libxl/libxl.c	Wed May 19 22:59:52 2010 +0100
>>>> +++ b/tools/libxl/libxl.c	Fri May 21 22:56:02 2010 +0800
>> ...snip...
>>>>      }
>>>>  
>>>> -    printf("setting domid %d memory to : %lld\n", domid, memorykb);
>>>> +    printf("setting domid %d memory to : %ld\n", domid, memorykb);
>>>>   
>>>
>>> This is wrong; "int64_t" isn't necessarily long.  What was wrong with
>>> the previous version?
>>
>> There's a problem. libxl_set_memory_target() takes memorykb as uint32_t,
>> so, if you want set as 'long long int', you should also modify this lib
>> function I think.
>> For this reason, when I set the memory to 100t, libxl_set_memory_target()
>> will take the memorykb as 0...
>>
> 
> Yes, we need to use uint64_t in libxenlight too, also I prefer uint64_t
> to unsigned long long.
> Finally in the printf call the best way to print a uint64_t in decimal
> format is using PRId64.
> 
> 

By the way, xc_domain_setmaxmem() take max_memkb as 'unsigned int'
It we use uint64_t, we should change that also.

> 
> 


-- 
Regards
Yang Hongyang

      parent reply	other threads:[~2010-05-26  1:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-21  7:01 [PATCH]xl: Some small fixes to xl Yang Hongyang
2010-05-21 14:26 ` Keir Fraser
2010-05-26  0:55   ` Yang Hongyang
2010-05-21 19:25 ` Jeremy Fitzhardinge
2010-05-24  0:48   ` Yang Hongyang
2010-05-24  9:16     ` Stefano Stabellini
2010-05-24 10:24       ` Ian Jackson
2010-05-24 10:31         ` Stefano Stabellini
2010-05-24 17:32           ` Jeremy Fitzhardinge
2010-05-26  1:02       ` Yang Hongyang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BFC733F.3010704@cn.fujitsu.com \
    --to=yanghy@cn.fujitsu.com \
    --cc=jeremy@goop.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.