All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH v5 RFC 05/14] tools/libxc: noarch common code
Date: Tue, 17 Jun 2014 17:28:59 +0100	[thread overview]
Message-ID: <53A06CCB.9010304@citrix.com> (raw)
In-Reply-To: <1403021435.25771.15.camel@kazak.uk.xensource.com>

On 17/06/14 17:10, Ian Campbell wrote:
> On Wed, 2014-06-11 at 19:14 +0100, Andrew Cooper wrote:
>> +int write_split_record(struct context *ctx, struct record *rec,
>> +                       void *buf, size_t sz)
>> +{
>> +    static const char zeroes[7] = { 0 };
>> +    xc_interface *xch = ctx->xch;
>> +    uint32_t combined_length = rec->length + sz;
>> +    size_t record_length = ROUNDUP(combined_length, REC_ALIGN_ORDER);
> I suppose the [7] must relate to REC_ALIGN_ORDER somehow, can you not
> derive it? (1<<REC_ALIGN_ORDER perhaps)

It does indeed.  I will change it to a calculation.

>
>> +
>> +    if ( record_length > REC_LENGTH_MAX )
>> +    {
>> +        ERROR("Record (0x%08"PRIx32", %s) length 0x%"PRIx32
>> +              " exceeds max (0x%"PRIx32")", rec->type,
>> +              rec_type_to_str(rec->type), rec->length, REC_LENGTH_MAX);
>> +        return -1;
>> +    }
>> +
>> +    if ( rec->length )
>> +        assert(rec->data);
>> +    if ( sz )
>> +        assert(buf);
>> +
>> +    if ( write_exact(ctx->fd, &rec->type, sizeof(rec->type)) ||
>> +         write_exact(ctx->fd, &combined_length, sizeof(rec->length)) ||
>> +         (rec->length && write_exact(ctx->fd, rec->data, rec->length)) ||
>> +         (sz && write_exact(ctx->fd, buf, sz)) ||
>> +         write_exact(ctx->fd, zeroes, record_length - combined_length) )
> For clarity I'd be inclined to split this into 4 separate ifs:
>   write type & length
>   optionally write data
>   optionally write extra buf
>   write padding.
>
> either goto err or a context specific PERROR.

Ok.

>
>> +    {
>> +        PERROR("Unable to write record to stream");
>> +        return -1;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +int write_record_header(struct context *ctx, struct record *rec)
>> +{
>> +    xc_interface *xch = ctx->xch;
>> +
>> +    if ( write_exact(ctx->fd, &rec->type, sizeof(rec->type)) ||
>> +         write_exact(ctx->fd, &rec->length, sizeof(rec->length)) )
> No need to round this one up? Or assert that it is already aligned?

The comment by the prototype explains that this is for use by "callers
doing complicated records" (i.e. PAGE_INFO) and that the caller is
responsible for ensuring that length is correct.

>
>> +    {
>> +        PERROR("Unable to write record to stream");
>> +        return -1;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>>  static void __attribute__((unused)) build_assertions(void)
>>  {
>>      XC_BUILD_BUG_ON(sizeof(struct ihdr) != 24);
>> diff --git a/tools/libxc/saverestore/common.h b/tools/libxc/saverestore/common.h
>> index cbecf0a..d9a3655 100644
>> --- a/tools/libxc/saverestore/common.h
>> +++ b/tools/libxc/saverestore/common.h
>> @@ -1,7 +1,20 @@
>>  #ifndef __COMMON__H
>>  #define __COMMON__H
>>  
>> +#include <stdbool.h>
>> +
>> +// Hack out junk from the namespace
> Do you have a plan to not need these hacks?

Not really.  There are enough other areas of libxc which still use these
macros, and I can't go and simply update all other areas as struct
context is meaningless outside of libxc/saverestore.

>
>> +     * required, the callee should leave '*pages' unouched.
> untouched.
>
>> +     * callee enounceters an error, it should *NOT* free() the memory it
> encounters.
>
>> + * ensuring that they subseqently write the correct amount of data into the
> subsequently.
>
>

Noted.

~Andrew

  reply	other threads:[~2014-06-17 16:28 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-11 18:14 [PATCH v5 0/14] Migration Stream v2 Andrew Cooper
2014-06-11 18:14 ` [PATCH v5 RFC 01/14] docs: libxc migration stream specification Andrew Cooper
2014-06-12  9:45   ` David Vrabel
2014-06-12 15:26   ` David Vrabel
2014-06-17 15:20   ` Ian Campbell
2014-06-17 17:42     ` Andrew Cooper
2014-06-17 16:40   ` Ian Campbell
2014-06-17 18:04     ` Andrew Cooper
2014-06-19  9:13       ` Hongyang Yang
2014-06-19  9:36         ` Andrew Cooper
2014-06-19 10:23           ` Hongyang Yang
2014-06-19 10:44             ` Andrew Cooper
2014-06-22 14:36               ` Shriram Rajagopalan
2014-06-22 16:01                 ` Andrew Cooper
2014-06-11 18:14 ` [PATCH v5 RFC 02/14] scripts: Scripts for inspection/valdiation of legacy and new streams Andrew Cooper
2014-06-12  9:48   ` David Vrabel
2014-06-11 18:14 ` [PATCH v5 RFC 03/14] [HACK] tools/libxc: save/restore v2 framework Andrew Cooper
2014-06-17 16:00   ` Ian Campbell
2014-06-17 16:17     ` Andrew Cooper
2014-06-17 16:47       ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 04/14] tools/libxc: C implementation of stream format Andrew Cooper
2014-06-12  9:52   ` David Vrabel
2014-06-12 15:31   ` David Vrabel
2014-06-17 15:55     ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 05/14] tools/libxc: noarch common code Andrew Cooper
2014-06-12  9:55   ` David Vrabel
2014-06-17 16:10   ` Ian Campbell
2014-06-17 16:28     ` Andrew Cooper [this message]
2014-06-17 16:53       ` Ian Campbell
2014-06-17 18:26         ` Andrew Cooper
2014-06-18  9:19           ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 06/14] tools/libxc: x86 " Andrew Cooper
2014-06-12  9:57   ` David Vrabel
2014-06-17 16:11     ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 07/14] tools/libxc: x86 PV " Andrew Cooper
2014-06-12  9:59   ` David Vrabel
2014-06-11 18:14 ` [PATCH v5 RFC 08/14] tools/libxc: x86 PV save code Andrew Cooper
2014-06-12 10:04   ` David Vrabel
2014-06-11 18:14 ` [PATCH v5 RFC 09/14] tools/libxc: x86 PV restore code Andrew Cooper
2014-06-12 10:08   ` David Vrabel
2014-06-12 15:49   ` David Vrabel
2014-06-12 17:01     ` Andrew Cooper
2014-06-17 16:22       ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 10/14] tools/libxc: x86 HVM common code Andrew Cooper
2014-06-12 10:11   ` David Vrabel
2014-06-17 16:22     ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 11/14] tools/libxc: x86 HVM save code Andrew Cooper
2014-06-12 10:12   ` David Vrabel
2014-06-12 15:55   ` David Vrabel
2014-06-12 17:07     ` Andrew Cooper
2014-06-17 16:25       ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 12/14] tools/libxc: x86 HVM restore code Andrew Cooper
2014-06-12 10:14   ` David Vrabel
2014-06-11 18:14 ` [PATCH v5 RFC 13/14] tools/libxc: noarch save code Andrew Cooper
2014-06-12 10:24   ` David Vrabel
2014-06-17 16:28     ` Ian Campbell
2014-06-17 16:38       ` David Vrabel
2014-06-17 16:54         ` Ian Campbell
2014-06-18  6:59   ` Hongyang Yang
2014-06-18  7:08     ` Hongyang Yang
2014-06-19  2:48   ` Wen Congyang
2014-06-19  9:19     ` Andrew Cooper
2014-06-22 14:02       ` Shriram Rajagopalan
2014-06-11 18:14 ` [PATCH v5 RFC 14/14] tools/libxc: noarch restore code Andrew Cooper
2014-06-12 10:27   ` David Vrabel
2014-06-12 16:05   ` David Vrabel
2014-06-12 17:16     ` Andrew Cooper
2014-06-19  6:16   ` Hongyang Yang
2014-06-19  9:00     ` Andrew Cooper
2014-06-12  3:17 ` [PATCH v5 0/14] Migration Stream v2 Hongyang Yang
2014-06-12 13:27   ` Andrew Cooper
2014-06-12 13:49     ` Wei Liu
2014-06-12 14:18       ` Andrew Cooper
2014-06-12 14:27         ` Wei Liu
2014-06-12  9:38 ` David Vrabel
2014-06-17 15:57   ` Ian Campbell

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=53A06CCB.9010304@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=frediano.ziglio@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /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.