xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Hanquez <vincent.hanquez@eu.citrix.com>
To: Andre Przywara <andre.przywara@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Keir Fraser <Keir.Fraser@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [PATCH 3/4] libxl: add version_info function [and 1 more messages]
Date: Tue, 20 Apr 2010 09:36:05 +0100	[thread overview]
Message-ID: <4BCD6775.7060800@eu.citrix.com> (raw)
In-Reply-To: <4BCCC062.5080008@amd.com>

On 19/04/10 21:43, Andre Przywara wrote:
> I am not fully convinced of this. There is quite a lot of information
> copied (up to 4KB), and some fields (like pagesize or the version
> numbers) are just plain integers. And this approach just propagates the
> underlying design.
> In the xl info implementation I used this feature to just get the
> pagesize. One could think of just querying the version number, too. If
> you don't like the additional parameter, what about a wrapping macro, then?
> I don't see the problem with the complexity, though, as it is hidden
> inside the library.

The query mask is exposed to the user, and the structure is partially 
filled. I can imagine that it's going to create those kind of issues, 
where the wrong mask is passed, or change later, and then the field the 
user was expecting would be left null.

The macro would help in the previous case, but I still feel it's 
unnecessary. As a user, I would just not bother, and call the function
always with full mask, until I reach the optimisation phase, and its 
appears on the graph.

A couple of K of data copied shouldn't make a difference, and would be 
completely lost in noise, however if you really think it makes a 
difference, you could have special dedicated info call to get specific 
things like version number.

> I can use libxl_sprintf function to get rid of the free() function, but
> I personally don't like the idea of accumulated mallocs much, left alone
> the "hidden" free operation.

There is a real advantage of permitting a fast development of libxl (and 
its bindings).

This was to get started at the beggining; when we reach a point where 
everything is working we could improve or remove the memory system. But 
I'm fairly convinced it's not going to make a difference for this kind 
of library.

-- 
Vincent

  reply	other threads:[~2010-04-20  8:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-18 21:17 [PATCH 0/4] Add "xl info" command Andre Przywara
2010-04-18 21:23 ` [PATCH 1/4] libxl: extend physinfo structure Andre Przywara
2010-04-19  7:50   ` Vincent Hanquez
2010-04-19 15:27     ` [PATCH 1/4] libxl: extend physinfo structure [and 1 more messages] Ian Jackson
2010-04-18 21:25 ` [PATCH 2/4] libxl: add sched_get_id function Andre Przywara
2010-04-19  7:50   ` Vincent Hanquez
2010-04-19 15:29     ` [PATCH 2/4] libxl: add sched_get_id function [and 1 more messages] Ian Jackson
2010-04-18 21:26 ` [PATCH 3/4] libxl: add version_info function Andre Przywara
2010-04-19  8:08   ` Vincent Hanquez
2010-04-19 15:36     ` [PATCH 3/4] libxl: add version_info function [and 1 more messages] Ian Jackson
2010-04-19 16:07       ` Vincent Hanquez
2010-04-19 16:21         ` Ian Jackson
2010-04-19 16:41           ` Vincent Hanquez
2010-04-19 20:43       ` Andre Przywara
2010-04-20  8:36         ` Vincent Hanquez [this message]
2010-04-21 12:10           ` Andre Przywara
2010-04-21 12:53             ` Vincent Hanquez
2010-04-18 21:28 ` [PATCH 4/4] xl: add "xl info" command Andre Przywara
2010-04-19 15:38   ` Ian Jackson

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=4BCD6775.7060800@eu.citrix.com \
    --to=vincent.hanquez@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=Keir.Fraser@eu.citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=andre.przywara@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).