Oh I love playing advocatus diaboli ;-)
* Jeremy Jackson jerj@coplanar.net [070611 16:58]:
Overall I disagree with flashrom being in userspace.
I have mixed feelings about the approach. As a hardware driver, it strictly belongs to the kernel. Oh, wait, in modern systems hardware drivers strictly belong into userspace, but Linux is not one of them.
At some point more than 50% of my effort went into keeping up with minor and major interface changes in the driver and while I thought I was maintaining it well, it suffered from bitrot and features like pci card flashing broke away since things in the kernel changed.
There is the issue of mapping PCI roms to free areas, locking (can you use the EEPROM socket on a NIC while it's receiving a frame?).
This depends very well on the card. The PCI standard forbids this anyways. Either the ROM or MEM/IO must be enabled, not both at the same time. Nonetheless, you can make sure it does not happen by unloading the network card module.
bloat and eases updates for new flash parts. This would let whole chip/sector erase, sector program of varying sector sizes, and any other chip specific functions be supported safely.
One rule of thumb you have to follow is: Do not run flashrom on an otherwise loaded machine. Then the timing is uncritical.
A simple whole-chip programming could be done with
# cat bios.rom > /dev/bios
cat for example always uses 4k blocks, which might lead to early destruction of the chip. dd bs=512k ... is much better.
With the hardware access moved into the kernel, the userspace tool(s) could focus on partial updates of code (boot block vs fallback vs normal images), userspace initramfs, kernels (on 2MB flash parts).
At what gain? And at what loss?
If you want to block other hw completely like /dev/bios did, you can just do cli/sti in a userspace program as well. That keeps timing issues away.
I agree flashrom should set itself to running with realtime policy enabled.
One thing that should really drive this home, is that using this architecture on Linux *and* Windows, the same userspace tool could be used on both, so the fancy code for incremental updates, writing parameter blocks, etc., wouldn't have to be duplicated.
It should not be duplicated anyways. The Windows driver currently only takes care of mapping memory into user space if I remember correctly.
Isn't MTD framework capable of handling most of this already?
Yes, it is. And it is incredibly complicated and complex for such a simple task. ie. it can be done, but MTD is designed for larger flash parts with filesystems on them. For BIOS chips it is a bit of a PITA.
Stefan