[flashrom] [Patch] Add coarse-grained IPC locking mechanism to Flashrom

[Carl-Daniel Hailfinger]

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 at google.com>
>   

No code review yet, because the design has to be agreed upon first.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/