summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* server/red_worker: use ack_data structAlon Levy2011-02-111-18/+20
| | | | start of move to red_channel based channels
* server/red_worker: change hold_item sig, drop the void*Alon Levy2011-02-111-4/+4
| | | | changed to PipeItem *
* update required minimal libcacard to 0.1.2Alon Levy2011-02-091-1/+1
|
* client/smartcard: libcacard dropped ReaderAddResponseAlon Levy2011-02-092-18/+78
| | | | | | | | | | | | uses VSC_Error with code==VSC_SUCCESS instead. This means that the VSC_Error message is overloaded. Instead of the other option of adding a message id, since the connection is TCP so no messages may be dropped or reordered, by having each message followed by a response there is no ambiguity. Still this commit adds a queue for messages that we only have one of which outstanding at a time, i.e. send, wait for response, send the next, etc. This further simplifies the logic, while not adding much overhead since only when spicec starts up it has a situation where it needs to send two events (ReaderAdd and ATR for Card Insert).
* server/smartcard: don't push our own error on reader addAlon Levy2011-02-091-3/+3
| | | | | | | | | | | | | | The device already sends one. There are actually two connections going on: server to client - this is the smartcard channel, it reuses the VSC protocol. server to device - this is an internal connection using VSC too. We generally just passthrough all messages from the client to the device, and from the device to the client. We only rewrite the reader_id because the device knows about a single id (it is actually a card id), and we may manage more then one in the future. Bottom line is that there was an extra VSC_Error message reaching the client.
* client/smartcard: ignore VSC_InitAlon Levy2011-02-071-0/+2
|
* server/smartcard: ignore VSC_Init from clientAlon Levy2011-02-071-0/+3
|
* server/smartcard: print instead of assert on bad reader_id in ↵Alon Levy2011-02-071-1/+3
| | | | smartcard_char_device_on_message_from_device
* server/smartcard: libcacard uses network byte order, so we must tooAlon Levy2011-02-071-6/+19
|
* client/smartcard: s/reader_id_t/uint32_t/ (libcacard changed)Alon Levy2011-02-072-11/+11
|
* server/smartcard: libcacard removed ReaderAddResponseAlon Levy2011-02-071-42/+4
|
* server/smartcard: s/reader_id_t/uint32_t/ (libcacard changed)Alon Levy2011-02-071-6/+6
|
* server/red_channel: style fix in red_channel_init_send_dataAlon Levy2011-02-071-2/+2
|
* server/red_channel: red_channel_pipe_clear: assert on NULL channelAlon Levy2011-02-071-1/+2
|
* server/red_channel: add TODOAlon Levy2011-02-071-0/+4
|
* server/red_channel: export red_channel_sendAlon Levy2011-02-072-1/+2
|
* server/red_channel: add red_channel_waiting_for_ackAlon Levy2011-02-071-4/+7
| | | | small inline function to have the ack window logic.
* server/red_channel: protect red_channel_push from NULLAlon Levy2011-02-071-0/+4
|
* server/red_channel: reset pipe_size on clear (from red_worker)Alon Levy2011-02-071-0/+1
|
* server/red_channel: red_channel_event: push on blockedAlon Levy2011-02-071-1/+6
| | | | | | | try to push either on signal (write available) or when blocked and read signaled. From red_worker, copied for compatibility when switching later to RedChannel in red_worker. Doesn't make a lot of sense (but works), see comment in patch.
* server/red_channel: use red_channel_receiveAlon Levy2011-02-071-1/+1
|
* server/red_channel: add empty handle of SPICE_MSGC_DISCONNECTINGAlon Levy2011-02-071-0/+2
| | | | Simply ignored in red_channel_handle_message
* server/red_channel: add red_channel_receive (for red_worker)Alon Levy2011-02-072-0/+13
|
* server/red_channel: unstatic red_channel_pipe_clear (for red_worker)Alon Levy2011-02-072-2/+5
|
* server/red_channel: unstatic red_channel_push (for red_worker)Alon Levy2011-02-072-2/+7
|
* server/red_channel: two 80 column fixesAlon Levy2011-02-071-4/+6
|
* server/red_channel: add public red_channel_default_peer_on_errorAlon Levy2011-02-072-5/+5
| | | | for later use in red_worker
* server/red_channel: add red_channel_pipe_add_after (from red_worker)Alon Levy2011-02-072-0/+11
|
* server/red_channel: make client ack window configurableAlon Levy2011-02-072-2/+5
| | | | from red_worker
* server/red_channel (tunnel): change sig of red_channel_handle_messageAlon Levy2011-02-073-8/+11
| | | | for later usage with red_worker
* server/red_channel: make MAX_SEND_VEC 100Alon Levy2011-02-071-1/+1
| | | | | | | | MAX_SEND_VEC was 100 for DisplayChannel's RedChannel implementation which is being replaced with RedChannel in red_channel. So changing from 50 to 100 in red_channel (make this configurble?) - effectively increased memory usage by: (100-50)*sizeof(iovec)*(num_of_channels-2) ==(arch 64bit) 50*16*6 ~ 5k Not terrible.
* server/red_channel: reflect SpiceDataHeader fields in handle_parsed_procAlon Levy2011-02-073-4/+4
|
* server/red_channel: add red_channel_pipe_add_pushAlon Levy2011-02-075-24/+32
|
* server/red_channel: add hold_item (from red_worker)Alon Levy2011-02-077-9/+41
| | | | | | | | | | | | | hold_item called on init_send_data, matching release. This is not the behavior of red_worker - we ref++ (==hold_item) when sending the item, and --refs when releasing it, instead of only holding if the send is blocked. Note 1: Naming: hold_pipe_item is the proc name, the variable is called hold_item, this is similar to release_item/release_pipe_item naming. Note 2: All channels have empty implementation, we later use this when red_worker get's RedChannelized.
* server/red_channel: add out_bytes_counter (unused)Alon Levy2011-02-072-0/+6
|
* client: log subject-host mismatch, and raise ssl warnings to errorsAlon Levy2011-02-071-5/+5
|
* configure.ac: use AC_LANG_SOURCE in AC_COMPILE_IFELSE, silence remaining ↵Alon Levy2011-02-071-3/+3
| | | | warnings
* server/red_worker: fix used but uninitialized warning (gcc 4.6.0)Alon Levy2011-02-071-1/+1
|
* spice-client migration: fix minor for old migration support.Uri Lublin2011-01-272-5/+5
| | | | | | | For not too old spice-migration, minor is 1. For older (ancient) spice-migration, minor is 0. Affects only VM migration while a spice client is connected.
* client/windows: don't allocate console unless requiredAlon Levy2011-01-271-9/+27
|
* client: fix broken vs2008 buildAlon Levy2011-01-274-4/+15
|
* client: --help should not need platform initializationAlon Levy2011-01-272-33/+62
| | | | | | separate initialization into before command line parsing and after, call later only if command line parsing succeeds (in particular, it "fails" if --help is given).
* demarshaller/marshaller fix gcc 4.6.0Alon Levy2011-01-252-9/+21
| | | | | | | | | | python_modules/demarshal.py and marshal.py fixes for gcc 4.6.0 warning about set but unused variables. The fixes disable creating of variables mem_size when they are not used (demarshall) and declaring a src variable when the message doesn't use it (marshal). You need to touch *.proto after applying this (should add a Makefile dependency).
* codegen: avoid creating out if not used (fix gcc 4.6.0 warning)Alon Levy2011-01-251-3/+5
|
* client: gcc 4.6.0: two more unused variable fixesAlon Levy2011-01-252-3/+0
|
* client/cegui: cegui 0.6.0 gcc 4.6.0 related fixAlon Levy2011-01-253-0/+8
| | | | | cegui doesn't include stddef required for ptrdiff_t type, we include it for it.
* client/glz_decoder.cpp: gcc 4.6.0 unused fixesAlon Levy2011-01-251-5/+0
|
* client/display_channel: gcc 4.6.0 unused fixesAlon Levy2011-01-251-6/+12
|
* common/sw_canvas: remove unused error valAlon Levy2011-01-251-2/+1
| | | | | | | | | | | This is the only unused var change I'll want to revisit eventually, I'm submitting anyway since it doesn't change current behavior. I'm talking about ignoring the return value from canvas creation. Adding a print is possible but I didn't test (may be too verbose, also preferable to be a debug print if so, and we don't have that option in the code atm - probably an environment variable will do, or adding some spice_server_set_logging_level api, maybe even spice_server_set_logging_fd?)
* common/canvas_base.c: remove unused variablesAlon Levy2011-01-251-12/+0
|