Otavio Salvador <ota...@ossystems.com.br> writes: > On Mon, Aug 4, 2014 at 6:37 PM, Richard Tollerton <rich.toller...@ni.com> > wrote: >> Otavio Salvador <ota...@ossystems.com.br> writes: >> >>> 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. >> >> Hmm, I'm confused. If we relied entirely on /dev contents, how would we >> detect (and correct for) if a device was removed between the execution >> of udev and of udev-cache? >> >>> 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". >> >> I agree that the copy of the contents of /dev needs to be as fast as >> possible -- your about using tmpfs as a staging area is well taken. But >> beyond that, it seems to me that the root issue you articulated is about >> ensuring adequate synchronization of udev.cache and the tarball; >> rereading CMP_FILE_LIST in udev-cache thus seems unavoidable. > > Yes, that's why I think we need: > > - copy contents to a staging area > - generate the tarball > > This way we avoid the following steps: > > - generate the list of contents > - generate the tarball > - generate tarball's contents > - compare, loop if does not match. > > Makes sense?
Yes, with one friendly amendment: "copy contents" means copying $CMP_FILE_LIST in addition to /dev. Then we rebuild cache.data from that. > -- > 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 -- Richard Tollerton <rich.toller...@ni.com> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
