Hi Joursoir,

Beside the internal programmer, most programmer manipulate only a few
things, so it is not that much. A data struct for each programmer
should be used to store the context of the programmer instead of
setting global variables. This gives the programmer a defined lifecycle
. The shutdown() function should take care of all initialized items
from the init() function. That can also be a pointer to memory mapped
I/O, a pci_dev or libusb context.

When we take a simple programmer like the drkaiser pci programmer,
there is a pci device, a pointer to memory mapped I/O and one register.
This can easily be handled in a few lines.

* The internal programmer is some kind of special, since it was part of
the flashrom core before other programmers exits.
* How to implement certain aspects is then part of the project.
* We try to reduce the amount of global variables. This project is part
of it.

-- Thomas

On Sat, 2022-03-19 at 15:59 +0300, Joursoir wrote:
> Hello Thomas and Anastasia,
> 
> Thank you for the quick answer. Now I understand the idea of the
> project more correctly. It really will be great if programmers
> have their own shutdown functions.
> 
> In your example you have used pci_write_*(), but the real flashrom
> code uses only rpci_write_* (it registers an undo-callback). Saving
> the data to some structure on every pci_write_*() is unnecessary
> complexity. So, we can continue to use rpci_write_*(), which will do
> work for us, but in a different way. The main problem is that
> register_shutdown() often occurs not in example_init(), but in its
> called funcs. Let's see on the example of internal programmer:
> 
> internal_init() -> chipset_flash_enable() -> 
> -> chipset_enables[i].doit() -> enable_flash_vt823x()
> 
> The last one can contain 1 or more rpci_write_*(). I suggest not to
> register shutdown in rcpi_write_*(), but to fill a linked list with
> value that should be restored. It will be restored in
> example_shutdown().
> 
> Should global variables be used? In the case of an internal
> programmer, struct example_data will go a long way before data is
> written to it.
> _______________________________________________
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org

_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

Reply via email to