Attention is currently required from: Hung-Te Lin, Subrata Banik, Edward O'Callaghan. Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/62213 )
Change subject: flashrom.c: Implement file-based locking semantics ......................................................................
Patch Set 2:
(3 comments)
Patchset:
PS2: Do we need a "big lock"? libusb based drivers, for instance, they have to call libusb_claim_interface() (I'm not sure though, if that's enough on all platforms). So they might be covered already. Generally, I'd prefer to lock individual resources, not the whole program.
Wasn't flashrom used in Chromebook manufacturing? Seems possible that they run only one instance per host, but I wouldn't have expected that.
FWIW, a sane candidate for locking is our physmap infrastructure. We could actually lock individual resources by encoding the base address into the file name, e.g. `flashrom.physmap-0x12345678.lock`. Port-based I/O also comes to mind.
File big_lock.h:
https://review.coreboot.org/c/flashrom/+/62213/comment/2f76fcbf_426a5bff PS2, Line 1: 2012
need update may be ?
Copyright lines are supposed to tell the date of the original publication. There are two lines... Was there anything significant added in the meantime? oO
File flashrom.c:
https://review.coreboot.org/c/flashrom/+/62213/comment/a40bde94_ae1e2d6d PS1, Line 142: programmer_entry
Not just futility - this is more like "can you run flashrom without getting root permission (required by lock)". I think people will want to simulate a flashrom call using dummy programmer (to create an image file) without adding 'sudo'.
Why would a lock need root permission? Can't we just place a file in `/tmp/`?
But on the other hand, it's also probably not a bad idea if we always require 'sudo' - even for unit tests. I'm fine if you want to keep the biglock always there.
FWIW, it's generally considered a bad idea to require `sudo`.