On Mon, Aug 4, 2014 at 6:18 PM, Richard Tollerton <rich.toller...@ni.com> wrote: > Otavio Salvador <ota...@ossystems.com.br> writes: > >> I am not sure about this one. I see the value you are adding here but >> I worry how often something can be connected during this process and >> change the contents along the way. Did you see something as that >> during your tests? > > No, but point taken. I didn't really test "physical" hotplug during > bootup -- and in particular, for this to be a persisting issue, the > added/removed device must be removed/added during this boot -- but I > suppose that is totally possible. > > This reflects an underlying race condition, starting at the computation > of NEWDATA/OLDDATA in the udev initscript, and ending in the tarball > creation in udev-cache. I suppose that we can mitigate this by spinning > in udev-cache until the devcache stops changing...? Cheesy, untested, > dirty RFC follows:
You need to check the list of files taken by 'tar' and compare. This mitigates it but does not really solves the issue. Maybe we could "copy" the nodes to a tmp area and use this as a snapshot? The copy should be fast and makes it mostly "atomic". -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
