On Fri, Mar 9, 2018 at 10:03 AM, Stefano Babic sbabic@denx.de wrote:
On 09/03/2018 10:54, Alex Kiernan wrote:
On Thu, Mar 8, 2018 at 5:04 PM, Stefano Babic sbabic@denx.de wrote:
Hi alex,
On 08/03/2018 12:52, Alex Kiernan wrote:
If the U-Boot environment is stored in a regular file and redundant operation isn't set, then write to a temporary file and perform an atomic rename.
Even if it is not explicitely set (IMHO it should), this code can be used as library and linked to own application. That means that concurrency can happens. I mean:
At this point you're writing the new environment, so we should hold a lock to avoid concurrent writes.
This is already done, even if not in the way I like. tools/env/fw_env_main.c calls flock() to acquire the resource. This works using fw_printenv / fw_setenv, but not as library. Library's users as me have to provide themselves a lock before calling the fw_* functions.
True... that particular implementation also causes me a different problem in that it fails on a read-only fs and I have a need for a call to fw_printenv before the filesystem has gone read-write.