SW_CANVAS_CACHE is always defined when building spice-gtk,
SW_CANVAS_IMAGE_CACHE is always defined when building spice-server, and
they are the only 2 users of spice-common. Moreover, build when none of
these is defined is broken.
All canvas_get_{quic,jpeg,lz4,jpeg_alpha,lz} methods have an 'invers'
argument, but are always called with that argument being 0, so we can
drop it from the argument list, and remove the code triggerring when
it's true.
Commit 4fafa210 added WARN_CFLAGS, VISIBILITY_HIDDEN_CFLAGS and
-std=gnu99 to AM_CFLAGS in common/Makefile.am, but these are not
needed. WARN_CFLAGS and VISIBILITY_HIDDEN_CFLAGS are not defined
anywhere in spice-common, and spice-common compiles fine without
-std=gnu99 on my f21 box.
AC_PATH_X sets a bunch of variables (x_includes, x_libraries, no_x)
after finding/not finding X. Since none of them are used afterwards,
having this check is not useful.
- Add a new LZ4 image type to spice.proto.
- Add canvas_get_lz4() to common_canvas_base, to get a pixmap from an
lz4 image.
- Add an enable-lz4 switch to the configure script, disabled by default.
The return of the get_array_size() is used as a limit in a loop,
being compared with an unsigned index (indexes are always unsigned).
To avoid the -Wsign-compare warning, let's cast the return of the
get_array_size() to unsigned and make GCC happier.
Although the most part of the parameters marked as unused are actually
being used for a few functions, a bunch of warnings can be seen when
the code is compiled with "-Wall -Wextra". As adding the unused attribute
means that the variable/parameter is meant to be *possibly* unused, we're
safe adding it in the generated code, even for used variables/parameters.
Check for MELCSTATES - 1 to get inside the branch, otherwise
(...)->rgb_state.melcstate may be up to MELCSTATES after the
pre-incrementing, which would result in an access to a position
that is out bounds of the array size MELCSTATES.
These 2 files are not build as part of spice-common
build system, but modules using spice-common will build
them with the appropriate options. We need to let automake
know that these are source files so that it can properly
track these files dependencies.
Without this change, when eg spice-gtk switches to use 'subdir-objects'
to build sw_canvas.c as recommended by automake 1.14, the build
will fail because $(top_srcdir)/spice-common/common/.deps/sw_canvas.Plo
will not have been generated.
Since the (de)marshallers are now generated in $builddir and not in
$srcdir, when these generated files include a file located in
$srcdir/common, the compiler will find them thanks to a -I directive, so it
makes more sense to use <> rather than "" when including them.
Now that they are created in $builddir, their includes will need to refer
to files in $srcdir, which can be different. It's cleaner to add
-I $(top_srcdir)/spice-common/ to modules using spice-common rather than
having -I $(top_srcdir)/spice-common/common which would could create header
collisions.
The rules to generate the .c/.h (de)marshalling files have targets based in
$builddir, but the CLIENT_MARSHALLERS/SERVER_MARSHALLERS list refer to
files in $srcdir.
When using a $srcdir != $builddir, these $srcdir files will not exist, and
it will not be possible to generate them, which causes the build to fail.
When using $srcdir == $builddir from git or from tarballs, this will not
make a difference. When building from git, if $srcdir and $builddir are the
same, then the files will be found regardless of if we look for them in
$srcdir or $builddir as they are the same.
In tarballs, the files will be shipped with the tarball and thus available
in $srcdir. As $builddir is the same as $srcdir, the files will already
exist and not be regenerated.
The only change of behaviour will be when using a tarball and doing a
$srcdir != $builddir build. In this case, the files will need to be
regenerated, so the tools needed for that must be installed on the
machine doing the build.
This channel provides a webdav server (rfc4918). This allows various
guest or remote system that support webdav to access a folder shared by
the client (some agent can be used to proxy the requests on a local port
for example). The webdav server may also be accessed by an hypervisor as
a remote filesystem interface, which can then be accessed by the guest
via other means (fs/fat emulation, mtp device, etc)
Due to the usage of a single channel stream and the need for concurrent
requests, webdav clients streams are multiplexed. Each client stream is
framed within 64k max messages (in little-endian)
int64 client_id
uint16 size
char data[size]
A new client_id indicates a new connection. A new communication stream
with the webdav server should be started. A client stream message of
size 0 indicates a disconnection of client_id. This multiplexed
communication happens over the channel "data" message.
Only when the port is opened may the communication be started.
A closed port event should close all currently known multiplexed
connections.
Why WebDAV?
webdav is supported natively by various OS for a long time (circa
Windows XP). It has several open-source implementations and a variety of
tools exist. A webdav implementation can be tested and used without a
Spice server or any virtualization (this also permit sharing the
implementation with other projects in the future, such as GNOME). It is
an IETF open standard and thus thoroughly specified.
The basic requirements for an efficient remote filesystem are provided
by the standard (pipelining, concurrency, caching, copy/move, partial
io, compression, locking ...) While other features are easily possible
via extensions to the protocol (common ones are executable attributes,
or searching for example).
Given the requirements, and the popularity of http/webdav, I believe it
is the best candidate for Spice remote filesystem support.
Other alternatives (adhoc, p9, smb2, sftp) have been studied and
discarded so far since they do not match in term of features or
requirements.
find_model_params() is first doing *nbuckets = 0; and it then checks
nbuckets for NULL. This is redundant as the dereferencing would cause a
segfault if nbuckets was NULL, so the if (nbuckets) test can't be false.
As Uri pointed out, the "/* bucket start */" comment on the same line
probably implies that the test was meant to be 'if (*nbuckets)'
I've ran a few test and I did not observe issues because of it...
If verify_subject() is called with a SpiceOpenSSLVerify struct containing a
non-NULL 'in_subject' member, it would try to use the local 'in_entries'
variable without having initialized it first. This could happen if
verify_subject() was called multiple time with the same SpiceOpenSSLVerify
context, which probably isn't occurring the way we are using it.
However, since verify_subject() is the only method which needs in_subject,
we don't need to have it stored in SpiceOpenSSLVerify, and we can
recreate it as needed locally in that method, which avoids that issue.
Unhandled values call an error callback, and then fall through the default:
case, which will call again the error callback. This commit adds some
break; after these cases to avoid this.
We are mostly likely not running as root, so this call will fail. As we are
supposed to check its return value as it's declared with
warn_unused_result, the current way of using it is wrong, so this commit just
removes the call.
Use same license as spice-gtk and spice modules (LGPL 2.1) since those licenses
applied to the spice-common submodule in the past. This makes it more clear
that if you use spice-common separately, the license is still LGPL. Also
mention license and copyright in generated files.
