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_mig_fill_wait_disconnect;
- reds_mig_cleanup_wait_disconnect;
- reds_mig_remove_wait_disconnect_client;
- reds_migrate_channels_seamless;
- reds_mig_finished;
- reds_mig_switch;
- reds_enable_mm_time;
- reds_disable_mm_time;
- attach_to_red_agent;
- reds_char_device_add_state;
- reds_char_device_remove_state;
- reds_on_char_device_state_destroy;
- spice_server_char_device_remove_interface;
- migrate_timeout.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
spice_warn_if_fail() is doing the same thing except for the inverted
condition. spice_warn_if() is being removed from spice-common to avoid
having potentially confusing redundancy.
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>
This patch and previous ones want to solve the problem of not having a
context in SpiceCoreInterface. SpiceCoreInterface defines a set of
callbacks to handle events in spice-server. These callbacks allow to
handle timers, watch for file descriptors and send channel events.
All these callbacks do not accept a context (usually in C passed as a
void* parameter) so it is hard for them to differentiate the interface
specified.
Unfortunately this structure is used even internally from different
contexts for instance every RedWorker thread has a different context. To
solve this issue some workarounds are used. Currently for timers a variable
depending on the current thread is used while for watches the opaque
parameter to pass to the event callback is used as it currently points just
to RedChannelClient structure. This however imposes some implicit
maintainance problem in the future. What happens for instance if for some
reason a timer is registered during worker initialization, run in another
thread? What if we decide to register a file descriptor callback for
something not a RedChannelClient? Could be that the program will run
without any issue till some bytes change and weird things could happen.
The implementation of this solution is done implementing an internal "core"
interface that has context specific and use it to differentiate the
context instead of relying on some other, hard to maintain, detail. Then an
adapter structure (name inpired to the adapter pattern) will provide the
internal core interface using the external, public, definition (in the
future this technique can be used to extend the external interface without
breaking the ABI).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
In some case the member specified to SPICE_CONTAINEROF was not
exactly the same type of the pointer passed.
This can cause issues if structure changes so use proper member.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
