On 10/25/21 11:45 PM, Wu, Hao wrote: >>>>>>>> The FPGA Image Load Framework was designed with the concept of >>>>>>>> transferring data to a device without imposing a purpose on the data. >>>>>>>> The expectation is that the lower-level driver or the device will >>>>>>>> validate the data. Is there something fundamentally wrong with that >>>>>>> I think there is something wrong here. As I said before, persistent >>>>>>> storage updating has different software process from some runtime >>>>>>> updating, so the class driver should be aware of what the HW engine >>>>>>> is doing. >>>>>> So far, there are no self-describing images that cause a >>>>>> change in run-time behavior, and I don't think that will >>>>>> happen for the very reason that the class-driver would >>>>>> need to know about it. >>>>> Again, the class driver needs to know what is happening, at some >>>>> abstraction level, to ensure the system is aligned with the HW state. >>>>> >>>>> If the class driver cannot tell the detail, it has to assume the >>>>> whole FPGA region will be changed, and removal & re-enumeration is >>>>> needed. >>>> So we make it a requirement that the self-describing files >>>> cannot make changes that require the class driver to manage >>>> state. >>> The API should not only define what it won't do, but also define what >>> it will do. But the "image load" just specifies the top half of the >>> process. So I don't think this API would be accepted. >> So what is the path forward. It seems like you are saying >> that the self-describing files do not fit in the fpga-mgr. >> Can we reconsider the FPGA Image Load Framework, which does >> not make any assumptions about the contents of the image >> files? > Why we need such "generic data transfer" interface in FPGA > framework? Are you referring to the use of self-describing files? or the generic nature of this class driver? > we need to handle the common need for FPGA > devices only, not all devices, like programming FPGA images. > So far we even don't know, what's the hardware response on > these self-describing files, how we define it as a common need > interface in the framework? The class driver does not _need_ to reside in the FPGA framework. I sent an inquiry to the maintainer of the Firmware update subsystem (and cc'd the kernel mailing list) and received no responses. I placed it under the FPGA framework only because the first user of the class driver is an FPGA driver. > If you just want to reuse the > fpga-mgr/framework code for your own purpose, Yes, it seems > saving some code for you, but finally it loses flexibility, as it's > not possible to extend common framework for your own > purpose in the future. If I understand correctly, you are saying that it doesn't fit well in the FPGA manager, because not all file types fit the definition of a firmware update? And future file types may not fit in fpga-mgr context? - Russ > > Thanks > Hao
