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

login
register
mail settings
Submitter Qi.Chen@windriver.com
Date Aug. 27, 2013, 7:08 a.m.
Message ID <f1e2a5ea20351fbe0e1e0552462752a5f5c70330.1377587203.git.Qi.Chen@windriver.com>
Download mbox | patch
Permalink /patch/56691/
State New
Headers show

Comments

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(-)
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

Patch

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