Commit Graph

18 Commits

Author SHA1 Message Date
Michal Privoznik
3b4df5d350 Drop needless ret variable
In few places we have the following code pattern:

  int ret;
  ... /* @ret is not accessed here */
  ret = f(...);
  return ret;

This pattern can be written less verbose:

  ...
  return f(...);

This patch was generated with following coccinelle spatch:

  @@
  type T;
  constant C;
  expression f;
  identifier ret;
  @@
  -T ret = C;
   ... when != ret
  -ret = f;
  -return ret;
  +return f;

Afterwards I needed to fix a few places, e.g. comment in
virDomainNetIPParseXML() was removed too because coccinelle
thinks it refers to @ret while in fact it doesn't. Also in few
places it replaced @ret declaration with a few spaces instead of
removing the line. But nothing terribly wrong.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2019-10-24 08:10:37 +02:00
John Ferlan
532e9a349b src: Use consistent error preservation and restoration calls
Provide some consistency over error message variable name and usage
when saving error messages across possible other errors or possibility
of resetting of the last error.

Instead of virSaveLastError paired up with virSetError and virFreeError,
we should use the newer virErrorPreserveLast and virRestoreError.

Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-16 15:24:40 -04:00
Michal Privoznik
4e42981b36 src: Unify virObject member name
Whenever we declare a new object the first member of the struct
has to be virObject (or any other member of that family). Now, up
until now we did not care about the name of the struct member.
But lets unify it so that we can do some checks at compile time
later.

The unified name is 'parent'.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-04-18 10:04:55 +02:00
Daniel P. Berrange
32d6c7386d Print hex values with '0x' prefix and octal with '0' in debug messages
Seeing a log message saying 'flags=93' is ambiguous & confusing unless
you happen to know that libvirt always prints flags as hex.  Change our
debug messages so that they always add a '0x' prefix when printing flags,
and '0' prefix when printing mode. A few other misc places gain a '0x'
prefix in error messages too.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-09-25 13:34:53 +01:00
Michal Privoznik
5b16a499f8 virStream*All: Report error if a callback fails
All of these four functions (virStreamRecvAll, virStreamSendAll,
virStreamSparseRecvAll, virStreamSparseSendAll) take one or more
callback functions that handle various aspects of streams.
However, if any of them fails no error is reported therefore
caller does not know what went wrong.

At the same time, we silently presumed callbacks to set errno on
failure. With this change we should document it explicitly as the
error is not properly reported.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-07-11 09:33:12 +02:00
Michal Privoznik
5b62dacb70 virStream*All: Preserve reported error
If one these four functions fail (virStreamRecvAll,
virStreamSendAll, virStreamSparseRecvAll, virStreamSparseSendAll)
the stream is aborted by calling virStreamAbort(). This is  a
public API; therefore, the first thing it does is error reset. At
that point any error that caused us to abort stream in the first
place is gone.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-07-11 08:59:04 +02:00
Michal Privoznik
6f8aa8e8da virStream*All: Call virStreamAbort() more frequently
Our documentation to the virStreamRecvAll, virStreamSendAll,
virStreamSparseRecvAll, and virStreamSparseSendAll functions
indicates that if these functions fail, then virStreamAbort is
called. But that is not necessarily true. For instance all of
these functions allocate a buffer to work with. If the allocation
fails, no virStreamAbort() is called despite -1 being returned.
It's the same story with argument sanity checks and a lot of
other checks.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-07-11 08:57:05 +02:00
Martin Kletzander
f1096c0247 docs: Add callback-related info to virStream{Abort,Finish}
When one has a non-blocking stream and aborts or finishes it without
removing the callback, any event loop invocation will trigger that
callback, but it cannot be removed any more.  We cannot remove the
callback automatically from virStream{Abort,Finish} functions due to
forward-compatibility.  So let's at least document this behaviour,
because it is not easy to find out the reason for.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2017-06-28 09:40:54 +02:00
Michal Privoznik
9b991d0237 virStreamSparseSendAll: Reset @want in each iteration
There's a slight problem with the current function. Assume we are
currently in a data section and we have say 42 bytes until next
section. Therefore, just before (handler) is called to fill up
the buffer with data, @want is changed to 42 to match the amount
of data left in the current section. However, after hole is
processed, we are back in data section but with incredibly small
@want size. Nobody will ever reset it back. This results in
incredible data fragmentation.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-22 15:25:39 +02:00
Michal Privoznik
84b5079232 Introduce virStreamInData
This is just an internal API, that calls corresponding function
in stream driver. This function will set @data = 1 if the
underlying file is in data section, or @data = 0 if it is in a
hole. At any rate, @length is set to number of bytes remaining in
the section the file currently is.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-18 07:42:13 +02:00
Michal Privoznik
a524951091 Introduce virStreamSparseSendAll
This is just a wrapper over new function that have been just
introduced: virStreamSendHole() . It's very similar to
virStreamSendAll() except it handles sparse streams well.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-18 07:42:13 +02:00
Michal Privoznik
3a1e2e920e Introduce virStreamSparseRecvAll
This is just a wrapper over new functions that have been just
introduced: virStreamRecvFlags(), virStreamRecvHole(). It's very
similar to virStreamRecvAll() except it handles sparse streams
well.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-18 07:42:13 +02:00
Michal Privoznik
87e4a842b7 Introduce VIR_STREAM_RECV_STOP_AT_HOLE flag
Add a new flag to virStreamRecvFlags in order to handle being able to
stop reading from the stream so that the consumer can generate a "hole"
in stream target. Generation of a hole replaces the need to receive and
handle a sequence of zero bytes for sparse stream targets.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-18 07:42:13 +02:00
Michal Privoznik
b6aedd2f05 Introduce virStreamRecvHole
This function is basically a counterpart for virStreamSendHole().
If one side of a stream called virStreamSendHole() the other
should call virStreamRecvHole() to get the size of the hole.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-18 07:42:13 +02:00
Michal Privoznik
69a573d010 Introduce virStreamSendHole
This API is used to tell the other side of the stream to skip
some bytes in the stream. This can be used to create a sparse
file on the receiving side of a stream.

It takes @length argument, which says how big the hole is. This
skipping is done from the current point of stream. Since our
streams are not rewindable like regular files, we don't need
@whence argument like seek(2) has.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-18 07:42:13 +02:00
Michal Privoznik
a35e2836b3 Introduce virStreamRecvFlags
This patch is adding the virStreamRecvFlags as a variant to the
virStreamRecv function in order to allow for future expansion of
functionality for processing sparse streams using a @flags
argument.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-05-18 07:42:13 +02:00
Michal Privoznik
809d02ca36 virStream{Recv,Send}All: Increase client buffer
These are wrappers over virStreamRecv and virStreamSend so that
users have to care about nothing but writing data into / reading
data from a sink (typically a file). Note, that these wrappers
are used exclusively on client side as the daemon has slightly
different approach. Anyway, the wrappers allocate this buffer and
use it for intermediate data storage until the data is passed to
stream to send, or to the client application. So far, we are
using 64KB buffer. This is enough, but suboptimal because server
can send messages up to VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX bytes
big (262120B, roughly 256KB). So if we make the buffer this big,
a single message containing the data is sent instead of four,
which is current situation. This means lower overhead, because
each message contains a header which needs to be processed, each
message is processed roughly same amount of time regardless of
its size, less bytes need to be sent through the wire, and so on.
Note that since server will never sent us a stream message bigger
than VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX there's no point in
sizing up the client buffer past this threshold.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-05-02 07:56:38 +02:00
Daniel P. Berrange
0c94d78bb5 Move virStream related APIs out of libvirt.c
Introduce a src/libvirt-stream.c file to hold all the
methods related to the virStream type.
2014-10-24 16:42:49 +01:00