[3/4] runqemu-internal: change the lock acquire/release logic

Submitted by Qi.Chen@windriver.com on Aug. 27, 2013, 7:08 a.m.

Details

Message ID f1e2a5ea20351fbe0e1e0552462752a5f5c70330.1377587203.git.Qi.Chen@windriver.com
State New
Headers show

Commit Message

Qi.Chen@windriver.com Aug. 27, 2013, 7:08 a.m.
From: Chen Qi <Qi.Chen@windriver.com>

Checking whether the lock file exists is sufficient for runqemu.
The contents of the lock file is not important.

This patch simplifies the lock acquire/release logic by removing the
flock mechanism. Also, we give more information to user indicating
why a tap interface is skipped.

As a side effect, the user now can easily create a lock file to
make runqemu skip a specific tap interface.

[YOCTO #5048]

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 scripts/runqemu-internal |   14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

Patch hide | download patch | download mbox

diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 8165e13..3f8674c 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -135,15 +135,12 @@  else
                 return 1
             fi
 
-            touch $lockfile.lock
-            exec 8>$lockfile.lock
-            flock -n -x 8
-            if [ $? -ne 0 ]; then
-                exec 8>&-
+            if [ -e $lockfile.lock ]; then
                 return 1
+            else
+                touch $lockfile.lock
+                return 0
             fi
-
-            return 0
         }
 
         release_lock() {
@@ -154,7 +151,6 @@  else
             fi
 
             rm -f $lockfile.lock
-            exec  8>&-
         }
 
         LOCKDIR="/tmp/qemu-tap-locks"
@@ -184,6 +180,8 @@  else
                 TAP=$tap
                 USE_PRECONF_TAP="yes"
                 break
+            else
+                echo "Skipping $tap as it's locked by $LOCKFILE.lock"
             fi
         done
 

Comments

Richard Purdie Aug. 27, 2013, 10:09 a.m.
On Tue, 2013-08-27 at 15:08 +0800, Qi.Chen@windriver.com wrote:
> From: Chen Qi <Qi.Chen@windriver.com>
> 
> Checking whether the lock file exists is sufficient for runqemu.
> The contents of the lock file is not important.

What happens if the runqemu script crashes and leaves the lockfile
around? Why are we removing perfectly functional code?

Cheers,

Richard
Phil Blundell Aug. 27, 2013, 10:14 a.m.
On Tue, 2013-08-27 at 15:08 +0800, Qi.Chen@windriver.com wrote:
> This patch simplifies the lock acquire/release logic by removing the
> flock mechanism.

I'm not sure that "simplifies" is an accurate description of the results
of removing flock.  How about "breaks"?

p.
Qi.Chen@windriver.com Aug. 28, 2013, 2:25 a.m.
On 08/27/2013 06:09 PM, Richard Purdie wrote:
> On Tue, 2013-08-27 at 15:08 +0800, Qi.Chen@windriver.com wrote:
>> From: Chen Qi <Qi.Chen@windriver.com>
>>
>> Checking whether the lock file exists is sufficient for runqemu.
>> The contents of the lock file is not important.
> What happens if the runqemu script crashes and leaves the lockfile
> around? Why are we removing perfectly functional code?
>
> Cheers,
>
> Richard
>
>
>
>

Yes. You're right.
I'll drop this patch and send out a V2.

Best Regards,
Chen Qi
Qi.Chen@windriver.com Aug. 28, 2013, 2:32 a.m.
On 08/27/2013 06:14 PM, Phil Blundell wrote:
> On Tue, 2013-08-27 at 15:08 +0800, Qi.Chen@windriver.com wrote:
>> This patch simplifies the lock acquire/release logic by removing the
>> flock mechanism.
> I'm not sure that "simplifies" is an accurate description of the results
> of removing flock.  How about "breaks"?
>
> p.
>
>
>
>
>
That would be a better description.
I then realized I did break the logic.
I'll drop this patch and send out a v2.

Best Regards,
Chen Qi