Attention is currently required from: Hung-Te Lin, Subrata Banik, Edward O'Callaghan.
3 comments:
Patchset:
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:
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:
Patch Set #1, 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`.
To view, visit change 62213. To unsubscribe, or for help writing mail filters, visit settings.