- 16 11月, 2018 1 次提交
-
-
由 Michal Privoznik 提交于
Revert "virlockspace: Allow caller to specify start and length offset in virLockSpaceAcquireResource" This reverts commit afd5a275. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 20 9月, 2018 1 次提交
-
-
由 Erik Skultety 提交于
All of the ones being removed are pulled in by internal.h. The only exception is sanlock which expects the application to include <stdint.h> before sanlock's headers, because sanlock prototypes use fixed width int, but they don't include stdint.h themselves, so we have to leave that one in place. Signed-off-by: NErik Skultety <eskultet@redhat.com> Acked-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 18 9月, 2018 1 次提交
-
-
由 Michal Privoznik 提交于
So far the virLockSpaceAcquireResource() locks the first byte in the underlying file. But caller might want to lock other range. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 04 4月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
We use the "vir" prefix pretty consistently in our APIs, both external and internal, which made these macros stood out.
-
- 08 6月, 2016 1 次提交
-
-
由 Tomáš Ryšavý 提交于
This function doesn't follow our convention of naming functions.
-
- 25 3月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
-
- 18 3月, 2014 2 次提交
-
-
由 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>
-
由 Martin Kletzander 提交于
Commit a1cbe4b5 added a check for spaces around assignments and this patch extends it to checks for spaces around '=='. One exception is virAssertCmpInt where comma after '==' is acceptable (since it is a macro and '==' is its argument). Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 08 10月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The test case average timing code has not been used by any test case ever. Delete it to remove complexity. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 26 9月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The virlockspacetest.c did not check for failure to create a lockspace, causing a crash on OOM Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 11 5月, 2013 1 次提交
-
-
由 Laine Stump 提交于
These all existed before virfile.c was created, and for some reason weren't moved. This is mostly straightfoward, although the syntax rule prohibiting write() had to be changed to have an exception for virfile.c instead of virutil.c. This movement pointed out that there is a function called virBuildPath(), and another almost identical function called virFileBuildPath(). They really should be a single function, which I'll take care of as soon as I figure out what the arglist should look like.
-
- 05 1月, 2013 1 次提交
-
-
由 John Ferlan 提交于
-
- 21 12月, 2012 4 次提交
-
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
- 16 10月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
The previously introduced virFile{Lock,Unlock} APIs provide a way to acquire/release fcntl() locks on individual files. For unknown reason though, the POSIX spec says that fcntl() locks are released when *any* file handle referring to the same path is closed. In the following sequence threadA: fd1 = open("foo") threadB: fd2 = open("foo") threadA: virFileLock(fd1) threadB: virFileLock(fd2) threadB: close(fd2) you'd expect threadA to come out holding a lock on 'foo', and indeed it does hold a lock for a very short time. Unfortunately when threadB does close(fd2) this releases the lock associated with fd1. For the current libvirt use case for virFileLock - pidfiles - this doesn't matter since the lock is acquired at startup while single threaded an never released until exit. To provide a more generally useful API though, it is necessary to introduce a slightly higher level abstraction, which is to be referred to as a "lockspace". This is to be provided by a virLockSpacePtr object in src/util/virlockspace.{c,h}. The core idea is that the lockspace keeps track of what files are already open+locked. This means that when a 2nd thread comes along and tries to acquire a lock, it doesn't end up opening and closing a new FD. The lockspace just checks the current list of held locks and immediately returns VIR_ERR_RESOURCE_BUSY. NB, the API as it stands is designed on the basis that the files being locked are not being otherwise opened and used by the application code. One approach to using this API is to acquire locks based on a hash of the filepath. eg to lock /var/lib/libvirt/images/foo.img the application might do virLockSpacePtr lockspace = virLockSpaceNew("/var/lib/libvirt/imagelocks"); lockname = md5sum("/var/lib/libvirt/images/foo.img"); virLockSpaceAcquireLock(lockspace, lockname); NB, in this example, the caller should ensure that the path is canonicalized before calculating the checksum. It is also possible to do locks directly on resources by using a NULL lockspace directory and then using the file path as the lock name eg virLockSpacePtr lockspace = virLockSpaceNew(NULL); virLockSpaceAcquireLock(lockspace, "/var/lib/libvirt/images/foo.img"); This is only safe to do though if no other part of the process will be opening the files. This will be the case when this code is used inside the soon-to-be-reposted virlockd daemon Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-