Hi David,
thanks for your patch!
Auf 01.02.2011 22:37, David Hendricks schrieb:
I have attached a patch which adds a locking mechanism to Flashrom to prevent multiple instances from running simultaneously. It may need some modification to fit different Flashrom use cases better, but I think it's a good start. [...] Disadvantages:
- The current patch is very coarse-grained, which could be problematic for
people who wish to flash multiple chips simultaneously.
That's the problem which might be the biggest hurdle. Users with Dediprog won't be happy about that.
From my perspective, we first have to make a design decision:
- Global lock - Programmer type lock - Programmer instance lock
If we decide to use the programmer instance lock, the internal programmer must use the programmer instance lock like a programmer type lock due to bus contention etc. A programmer instance lock would be extremely useful for Dediprog, FT2232, anything Serprog and EZo/Willem devices. For PCI-based programmers the usefulness is debatable because those usually use a busy loop for timing, and having more than one such busy-loop run at the same time will screw up timing. In fact, even a programmer type lock would not be sufficient here because nic3com, internal, satasii and others all use the same busy loop for timing.
Side note: If you have any active (i.e. consuming CPU) processes in the background or if you have any CPU frequency scaling daemon active in the background, timing is guaranteed to be shot. SPI flash does not really care about timing, so you probably won't notice it on the Cr-48 laptop. It may cause random corruption on devices with parallel or LPC/FWH flash, though. NOTE: flashrom qualifies as CPU-consuming process. A way to prevent timing mishaps is to dedicate one CPU core to each flashrom instance.
In short: Either you use timing-insensitive flash (usually SPI) or you use n CPU cores for n flashrom instances. Anything else will result in timing-related corruption which may or may not be below the threshold which triggers flashrom to abort.
- Requires >= POSIX.1-2001 compliance.
That will be difficult to get on Windows and DOS, and I'd like to see some tests on OSX/*BSD/OpenSolaris as well. We'll need a test for working locking, though. I fear there might be systems out there which advertise POSIX.1-2001 compliance to get stuff to compile, but which are missing real locking. Then there's the problem of running flashrom on top of libpayload. Do we need locking for that? Probably not until libpayload grows into a lightweight OS.
Signed-off-by: David Hendricks dhendrix@google.com
No code review yet, because the design has to be agreed upon first.
Regards, Carl-Daniel