That's right, if you wanna stick "FreeEMS Compatible" or "Works with FreeEMS" on your software, for the sake of all users, it MUST support serial device locking. This is not optional and anything that wants to be official software should have this in place and working on all three platforms by the time 0.2.0 of the firmware is released.
I've personally lost too much time with this, and I know for a fact that others have too.
In general serial locking is a bit of a mess, however there is no reason that we can't synchronise our own applications between us. It doesn't matter if it doesn't work with other apps that use the port, chances of having those running at the same time = slim to none anyway. Chances of forgetting the loader is still connected or that emstudio or mtx or lacerated pempheridae etc are still connected is very high and happens regularly to both users and developers.
It'd be better if we went with something as standard as possible so as to increase the chance of it working with random other apps.
Windows, Mike says it's on by default. Verify this.
Linux, what's the best way to go?
OSX, what's the best way to go?
Hash it out here, folks, this should be a priority for all developers.
Fred.
Mandatory Device Locking For FreeEMS Compatible Apps
Mandatory Device Locking For FreeEMS Compatible Apps
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
-
- LQFP112 - Up with the play
- Posts: 119
- Joined: Sat Apr 24, 2010 1:42 am
- Location: New Zealand
Re: Mandatory Device Locking For FreeEMS Compatible Apps
Is this just managing a file in /run/lock/ to say when the port is in use?
Re: Mandatory Device Locking For FreeEMS Compatible Apps
Yeah, pretty much. But in a way that is guaranteed to work inside our project.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
-
- LQFP112 - Up with the play
- Posts: 211
- Joined: Tue May 01, 2012 4:17 pm
- Location: Shrewsbury PA
- Contact:
Re: Mandatory Device Locking For FreeEMS Compatible Apps
From http://en.wikipedia.org/wiki/File_locking
"Although some types of locks can be configured to be mandatory, file locks under Unix are by default advisory. This means that cooperating processes may use locks to coordinate access to a file among themselves, but uncooperative processes are also free to ignore locks and access the file in any way they choose. In other words, file locks lock out other file lockers only, not I/O."
In other words, as long as we all support locking, we can't screw up each other, but other people can still screw us up. I reccomend http://linux.die.net/man/2/flock on Linux.
"Although some types of locks can be configured to be mandatory, file locks under Unix are by default advisory. This means that cooperating processes may use locks to coordinate access to a file among themselves, but uncooperative processes are also free to ignore locks and access the file in any way they choose. In other words, file locks lock out other file lockers only, not I/O."
In other words, as long as we all support locking, we can't screw up each other, but other people can still screw us up. I reccomend http://linux.die.net/man/2/flock on Linux.
-
- LQFP112 - Up with the play
- Posts: 211
- Joined: Tue May 01, 2012 4:17 pm
- Location: Shrewsbury PA
- Contact:
Re: Mandatory Device Locking For FreeEMS Compatible Apps
[21:29] -emstudio-dev:#freeems-dev- [emstudio] malcom2073 pushed 1 new commit to dev: http://git.io/tf8slg
[21:29] -emstudio-dev:#freeems-dev- [emstudio/dev] Addition of advisory lock upon opening serial port in linux - Michael Carpenter
[21:29] -emstudio-dev:#freeems-dev- [emstudio/dev] Addition of advisory lock upon opening serial port in linux - Michael Carpenter
Re: Mandatory Device Locking For FreeEMS Compatible Apps
Exactly!malcom2073 wrote:From http://en.wikipedia.org/wiki/File_locking
"Although some types of locks can be configured to be mandatory, file locks under Unix are by default advisory. This means that cooperating processes may use locks to coordinate access to a file among themselves, but uncooperative processes are also free to ignore locks and access the file in any way they choose. In other words, file locks lock out other file lockers only, not I/O."
In other words, as long as we all support locking, we can't screw up each other, but other people can still screw us up. I reccomend http://linux.die.net/man/2/flock on Linux.
So, I reviewed your code, and it looks good. Unfortunately I don't have a compliant locking app to test against. I note that no files get created in /var/lock, but that I had stale locks laying around in there from an unknown source:
fred@cheetah:/mnt/video/tv/Animaniacs 1-50$ l /var/lock/
total 8
-rw-r--r-- 1 fred fred 10 Aug 30 16:27 LCK..ttyUSB1
-rw-r--r-- 1 fred fred 10 Aug 30 16:24 LCK..ttyUSB2
At first I thought "maybe it was the warner brothers (and the warner sister, Dot!)?, then I found the source:
fred@cheetah:~/workspaces/MegaTunix$ grep -rn LCK\.\. .
./src/locking.c:239: tmpbuf = g_strdup_printf("/var/lock/LCK..");
./msloader/loader_common.c:239: lock = g_strdup_printf("/var/lock/LCK..");
These files contain a PID so I tried to test it by running against itself, which in the past worked, but failed with this:
So I filed an issue on Dave's private, censored tracker: http://megatunix.com/tracker/view.php?id=25
Then I checked for open semantics matching yours
fred@cheetah:~/workspaces/MegaTunix$ grep -rn LOCK_ . | grep -v Binary | grep -v BLOCK | grep -v CLOCK
fred@cheetah:~/workspaces/MegaTunix$
But no such luck. So I filed another issue on Dave's private, censored tracker: http://megatunix.com/tracker/view.php?id=26
I also tried cutecom, though I didn't check the source for LOCK open calls, yet. It didn't play nice with emstudio, either way. Checked, nothing:
fred@cheetah:~/Downloads/cc/cutecom-0.22.0$ grep -rn LOCK .
fred@cheetah:~/Downloads/cc/cutecom-0.22.0$
Thank you for your very quick turn around on that! Let's see if we can get at least two apps to work nicely together in the short term. Perhaps John would like to take a stab?
Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: Mandatory Device Locking For FreeEMS Compatible Apps
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: Mandatory Device Locking For FreeEMS Compatible Apps
Dave's taken offense to the private, secret, censored comments. It's not private, that is true... See his #26 for more info.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: Mandatory Device Locking For FreeEMS Compatible Apps
Now that Dave has cleared out his "only one MTX" feature/bug I've tested his implementation and, superficially, it appears to work. I'm not going to invest time into seeing if parallel creation of the file is properly handled or not, though. There could still be concurrency issues present there.
Dave, if you're reading this, pay special attention to the first post.
Fred.
Dave, if you're reading this, pay special attention to the first post.
Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: Mandatory Device Locking For FreeEMS Compatible Apps
Dare I mention live data stream viewing with OLV?