- 18 5月, 2017 6 次提交
-
-
由 Michal Privoznik 提交于
This function will fetch previously processed stream holes and return their sum. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This is a function that handles an incoming STREAM_HOLE packet. Even though it is not wired up yet, it will be soon. At the beginning do couple of checks whether server plays nicely and sent us a STREAM_HOLE packed only after we've enabled sparse streams. Then decodes the message payload to see how big the hole is and stores it in passed @length argument. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
While the previous commit implemented a helper for sending a STREAM_HOLE packet for daemon, this is a client's counterpart. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Add a new argument to daemonCreateClientStream in order to allow for future expansion to mark that a specific stream can be used to skip data, such as the case with sparsely populated files. The new flag will be the eventual decision point between client/server to decide whether both ends can support and want to use sparse streams. A new bool 'allowSkip' is added to both _virNetClientStream and daemonClientStream in order to perform the tracking. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Add a virStreamPtr pointer to the _virNetClientStream in order to reverse track the parent stream. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 4月, 2017 1 次提交
-
-
由 Marc Hartmayer 提交于
Use the return value of virObjectRef directly. This way, it's easier for another reader to identify the reason why the additional reference is required. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
-
- 02 5月, 2016 2 次提交
-
-
由 Michal Privoznik 提交于
There are two functions on the client that handle incoming stream data. The first one virNetClientStreamQueuePacket() is a low level function that just processes the incoming stream data from the socket and stores it into an internal structure. This happens in the client event loop therefore the shorter the callbacks are, the better. The second function virNetClientStreamRecvPacket() then handles copying data from internal structure into a client provided buffer. Change introduced in this commit makes just that: new queue for incoming stream packets is introduced. Then instead of copying data into intermediate internal buffer and then copying them into user buffer, incoming stream messages are queue into the queue and data is copied just once - in the upper layer function virNetClientStreamRecvPacket(). In the end, there's just one copying of data and therefore shorter event loop callback. This should boost the performance which has proven to be the case in my testing. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This reverts commit d9c9e138. Unfortunately, things are going to be handled differently so this commit must go. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 23 9月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 03 8月, 2015 1 次提交
-
-
由 Ossi Herrala 提交于
Use I/O vector (iovec) instead of one huge memory buffer as suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1026137#c7. This avoids doing memmove() to big buffers and performance doesn't degrade if source (virNetClientStreamQueuePacket()) is faster than sink (virNetClientStreamRecvPacket()). Resolves: http://bugzilla.redhat.com/1026137Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 25 3月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
-
- 18 3月, 2014 1 次提交
-
-
由 Daniel P. Berrange 提交于
Any source file which calls the logging APIs now needs to have a VIR_LOG_INIT("source.name") declaration at the start of the file. This provides a static variable of the virLogSource type. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 10 7月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
-
- 16 1月, 2013 2 次提交
-
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
Currently all classes must directly inherit from virObject. This allows for arbitrarily deep hierarchy. There's not much to this aside from chaining up the 'dispose' handlers from each class & providing APIs to check types. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 21 12月, 2012 5 次提交
-
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
Since the event APIs are now in the public header, no internal code should include virevent.h
-
- 21 9月, 2012 1 次提交
-
-
由 Eric Blake 提交于
https://www.gnu.org/licenses/gpl-howto.html recommends that the 'If not, see <url>.' phrase be a separate sentence. * tests/securityselinuxhelper.c: Remove doubled line. * tests/securityselinuxtest.c: Likewise. * globally: s/; If/. If/
-
- 07 8月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
Make all the virNetClient* objects use virObject APIs for reference counting Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 23 7月, 2012 1 次提交
-
-
由 Osier Yang 提交于
Per the FSF address could be changed from time to time, and GNU recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html) You should have received a copy of the GNU General Public License along with Foobar. If not, see <http://www.gnu.org/licenses/>. This patch removes the explicit FSF address, and uses above instead (of course, with inserting 'Lesser' before 'General'). Except a bunch of files for security driver, all others are changed automatically, the copyright for securify files are not complete, that's why to do it manually: src/security/security_selinux.h src/security/security_driver.h src/security/security_selinux.c src/security/security_apparmor.h src/security/security_apparmor.c src/security/security_driver.c
-
- 18 7月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
This rmoves all the per-file error reporting macros from the code in src/rpc/ Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 04 6月, 2012 1 次提交
-
-
由 Radu Caragea 提交于
The stream lock is unlocked twice instead of being locked and then unlocked. Probably a typo.
-
- 12 1月, 2012 1 次提交
-
-
由 Michal Privoznik 提交于
If client stream does not have any data to sink and neither received EOF, a dummy packet is sent to the daemon signalising client is ready to sink some data. However, after we added event loop to client a race may occur: Thread 1 calls virNetClientStreamRecvPacket and since no data are cached nor stream has EOF, it decides to send dummy packet to server which will sent some data in turn. However, during this decision and actual message exchange with server - Thread 2 receives last stream data from server. Therefore an EOF is set on stream and if there is a call waiting (which is not yet) it is woken up. However, Thread 1 haven't sent anything so far, so there is no call to be woken up. So this thread sent dummy packet to daemon, which ignores that as no stream is associated with such packet and therefore no reply will ever come. This race causes client to hang indefinitely.
-
- 16 11月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
Stop multiplexing virNetClientSend for two different purposes, instead add virNetClientSendWithReply and virNetClientSendNoReply * src/rpc/virnetclient.c, src/rpc/virnetclient.h: Replace virNetClientSend with virNetClientSendWithReply and virNetClientSendNoReply * src/rpc/virnetclientprogram.c, src/rpc/virnetclientstream.c: Update for new API names
-
- 11 10月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
If we receive an error on the stream, set the EOF marker so that any further (bogus) incoming data is dropped. * src/rpc/virnetclientstream.c: Set EOF on stream
-
- 23 9月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
commit 984840a2 removed the notification of waiting calls when VIR_NET_CONTINUE messages arrive. This was to fix the case of a virStreamAbort() call being prematurely notified of completion. The problem is that sometimes there are dummy calls from a virStreamRecv() call waiting that *do* need to be notified. These dummy calls should have a status VIR_NET_CONTINUE. So re-add the notification upon VIR_NET_CONTINUE, but only if the waiter also has a status of VIR_NET_CONTINUE. * src/rpc/virnetclient.c: Notify waiting call if stream data arrives * src/rpc/virnetclientstream.c: Mark dummy stream read packet with status VIR_NET_CONTINUE
-
- 01 9月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
Commit 2c85644b attempted to fix a problem with tracking RPC messages from streams by doing - if (msg->header.type == VIR_NET_REPLY) { + if (msg->header.type == VIR_NET_REPLY || + (msg->header.type == VIR_NET_STREAM && + msg->header.status != VIR_NET_CONTINUE)) { client->nrequests--; In other words any stream packet, with status NET_OK or NET_ERROR would cause nrequests to be decremented. This is great if the packet from from a synchronous virStreamFinish or virStreamAbort API call, but wildly wrong if from a server initiated abort. The latter resulted in 'nrequests' being decremented below zero. This then causes all I/O for that client to be stopped. Instead of trying to infer whether we need to decrement the nrequests field, from the message type/status, introduce an explicit 'bool tracked' field to mark whether the virNetMessagePtr object is subject to tracking. Also add a virNetMessageClear function to allow a message contents to be cleared out, without adversely impacting the 'tracked' field as a naive memset() would do * src/rpc/virnetmessage.c, src/rpc/virnetmessage.h: Add a 'bool tracked' field and virNetMessageClear() API * daemon/remote.c, daemon/stream.c, src/rpc/virnetclientprogram.c, src/rpc/virnetclientstream.c, src/rpc/virnetserverclient.c, src/rpc/virnetserverprogram.c: Switch over to use virNetMessageClear() and pass in the 'bool tracked' value when creating messages.
-
- 08 7月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
In one exit path we forgot to free the virNetMessage object causing a large memory leak for streams which send a lot of data. Some other paths were calling VIR_FREE directly instead of virNetMessageFree although this was (currently) harmless. * src/rpc/virnetclientstream.c: Fix leak of msg object * src/rpc/virnetclientprogram.c: Call virNetMessageFree instead of VIR_FREE
-
- 29 6月, 2011 3 次提交
-
-
由 Daniel P. Berrange 提交于
When the remote client receives end of file on the stream it never invokes the stream callback. Applications relying on async event driven I/O will thus never see the EOF condition on the stream * src/rpc/virnetclient.c, src/rpc/virnetclientstream.c: Ensure EOF is dispatched
-
由 Daniel P. Berrange 提交于
The client stream object can be used independently of the virNetClientPtr object, so must have full locking of its own and not rely on any caller. * src/remote/remote_driver.c: Remove locking around stream callback * src/rpc/virnetclientstream.c: Add locking to all APIs and callbacks
-
由 Daniel P. Berrange 提交于
* src/rpc/virnetclientstream.c: Avoid referencing NULL
-
- 24 6月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
To facilitate creation of new clients using XDR RPC services, pull alot of the remote driver code into a set of reusable objects. - virNetClient: Encapsulates a socket connection to a remote RPC server. Handles all the network I/O for reading/writing RPC messages. Delegates RPC encoding and decoding to the registered programs - virNetClientProgram: Handles processing and dispatch of RPC messages for a single RPC (program,version). A program can register to receive async events from a client - virNetClientStream: Handles generic I/O stream integration to RPC layer Each new client program now merely needs to define the list of RPC procedures & events it wants and their handlers. It does not need to deal with any of the network I/O functionality at all.
-