All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pavel Dovgaluk" <Pavel.Dovgaluk@ispras.ru>
To: 'Jan Kiszka' <jan.kiszka@siemens.com>
Cc: 'qemu-devel' <qemu-devel@nongnu.org>, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH] Fix serial interface vmstate
Date: Wed, 22 Jun 2011 13:15:46 +0400	[thread overview]
Message-ID: <000001cc30bc$f89067e0$e9b137a0$@Dovgaluk@ispras.ru> (raw)
In-Reply-To: <4E01B16A.50602@siemens.com>

> >>>   What is the purpose of subsections?
> >>
> >> To skip the new fields whenever possible. That would allow to continue
> >> saving a vmstate on a new version of qemu and then restoring it on an
> >> older one.
> >
> >   Do you have an idea how to implement "needed" function for my case?
> > Because I think, these fields should always be saved and loaded, because
> > they are related to the main state of the interface, not the kind of
> > optional substate.
> 
> E.g., if the fifo is empty, you do not need to save its content. That
> would be one part of the condition. Go through all fields and check if
> they have states that could be ignored or if they could be ignored if
> other already saved fields have specific values. If you find any new
> field that must always be restored, let us discuss it. It may turn out
> that a substate is unrealistic, then we need to go with a new version.

  You mean, if FIFO is empty an will not be saved, we will have to clear
it before loading every time?
  So there should be multiple subsections for every possible field?
  E.g. timers are saved only if they are pending, thr_ipending is saved
only when it is nonzero, and so on. Do you mean that?
  
Pavel Dovgaluk

  reply	other threads:[~2011-06-22  9:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-21 12:23 [Qemu-devel] [PATCH] Fix serial interface vmstate Pavel Dovgaluk
2011-06-21 13:31 ` Juan Quintela
2011-06-22  6:19   ` Pavel Dovgaluk
     [not found]   ` <49270.9042774097$1308723700@news.gmane.org>
2011-06-22  8:12     ` Jan Kiszka
2011-06-22  8:58       ` Pavel Dovgaluk
2011-06-22  9:10         ` Jan Kiszka
2011-06-22  9:15           ` Pavel Dovgaluk [this message]
2011-06-22  9:22             ` Jan Kiszka
2011-06-22 10:13               ` Pavel Dovgaluk
2011-06-22 16:14                 ` Jan Kiszka
     [not found]       ` <4e01af43.ce4ee50a.60ee.3b47SMTPIN_ADDED@mx.google.com>
2011-06-23 10:11         ` Andreas Färber

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='000001cc30bc$f89067e0$e9b137a0$@Dovgaluk@ispras.ru' \
    --to=pavel.dovgaluk@ispras.ru \
    --cc=jan.kiszka@siemens.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.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.