Remove the need to release the item inside send_item callbacks.
This looks like a partial rollback of previous patch but is
to make clear the intention of the change.
The lifetime of items could extend a bit further but there
are no cases this small lag should cause problems.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This is quite confusing and prone to errors.
Use RedPipeItem reference counting instead.
To compensate for the additional reference due to red_pipe_item_ref
in RedChannel sub class with empty hold_item have to add a
red_pipe_item_unref call in send_item.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Avoid having to provide a lot of empty implementations
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This code make easier to be sure we don't have dangling pointers
resetting in the function which free the structure.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Now that all derived classes use a type deriving from PipeItem for their
RedCharDeviceMsgToClient, we can make this explicit in the
RedCharDeviceClass vfuncs, and remove the RedCharDeviceMsgToClient
typedef.
This structure holding virtual function pointers was kept until now as a
RedCharDevice member in order to make the GObject conversion easier.
Now that all RedCharDevice children are converted to GObject, it can be
moved into RedCharDeviceClass.
This inherits from RedCharDevice. Once all char device states are
converted, we can turn the associated vfuncs into RedCharDeviceClass
vfuncs.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
make the function names match the type names. So
spice_char_device_state_* becomes red_char_device_* and
spice_char_device_* also becomes red_char_device_*.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This is more consistent with internal type naming convention, and it
paves the way for a new char device GObject heirarchy
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Move all internal data into a private struct so that it won't be exposed
when we move SmartCardDeviceState into the header.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
No need to have callback registered internally no static
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This should be the final piece of removing the global reds variable. We
still need a global variable to clean up during the atexit() function,
but we use a GList of servers (even though we technically don't support
multiple servers in the same process yet).
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's always called at the same time as red_channel_register_client_cbs()
and the data is used by the callbacks, so we can pass the data as an
argument to red_channel_register_client_cbs().
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
APDUBufSize is only used within smartcard.c, no need to expose it in
smartcard.h
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The RedChannel argument is not used by pipe_item_init. Removing it
will make code simpler in places where we don't have a RedChannel
directly available.
This is acting on a PipeItem object so correct name is pipe_item_init.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Store a reference to the server in the SpiceCharDeviceState struct and
use that rather than the global 'reds' variable
Acked-by: Frediano Ziglio <fziglio@redhat.com>
In preparation for getting rid of the global 'reds' variable, we need to
pass the RedsState variable to all functions where it is needed. For now
the callers just pass in the global reds variable.
Functions changed:
- reds_register_channel;
- reds_unregister_channel;
- reds_get_mouse_mode;
- reds_set_mouse_mode;
- reds_update_mouse_mode;
- reds_agent_remove;
- reds_find_channel;
- reds_mig_cleanup;
- reds_reset_vdp;
- reds_main_channel_connected;
- reds_client_disconnect;
- reds_disconnect;
- reds_mig_disconnect.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Make clear that these funcion are just checking a condition.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The current solution just copy the buffer. Currently data that is read
from the guest is always copied before sending it to the client. When we
will have ref count for these buffers, we can also use it for marshalling
the migration data.
If reading/writing from the device have occured before migration data
has arrived, the migration data might no longer be relvant, and we
disconnect the client.
Attach/detach a client to a SpiceCharDeviceState upon its
connection/disconnection, instead of upon reader_add/remove messages.
When the client is removed from a SpiceCharDeviceState, all the
messages from this client are removed from the device write queue.
This shouldn't happen when we only receive reader_remove and the
client is still connected.
With SpiceCharDeviceState, the smartcard code now supports partial writes,
and storing data that is received from the client after the device is
stopped, instead of attempting to write it to the guest.
The lifetime of the channel is not necessarily correlated to the life
time of the device. In the next patch, we need to keep a reference
to SpiceCharDeviceWriteBuffer, which might be in use even if the
SpiceCharDeviceState is destroyed, but the channel is still connected.
The next patch keeps this reference inside SmartCardChannelClient.
This patch also removes the routine smartcard_readers_detach_all(rcc), which
is unnecessary since we don't support multiple readers; even when
we do support them, each channel client should be associated with only
one reader (i.e., we will have different channels for different
readers).
This patch and the following one do not introduce tokening to the smartcard
channel. But this can be done easily later, by setting the appropriate
variables in SpiceCharDeviceState (after adding the appropriate protocol messages,
and implementing this in the client side).
