> -----Original Message----- > From: Borislav Petkov [mailto:bp@xxxxxxxxx] > Sent: Wednesday, February 25, 2015 8:49 PM > > On Wed, Feb 25, 2015 at 12:38:20PM +0000, Kweh, Hock Leong wrote: > > The reason we use this interface for efi capsule is that efi capsule > > support multi binaries to be uploaded and each binary file name > > can be different. > > So you can write the file path to a second file and reload then, once > per file. Thanks for the suggestion. Did some exploration on this approach and would like to continue the discussion together with this suggested design. Ideal condition: - one file note is enough for load binary and status return (capsule_load) - load steps would be as simple as just: echo [binary file name] > capsule_load - status return in the same command action. If failed, the echo will fail with the failing status code. Trade off: - does not have the run time flexibility to load any firmware binaries at different different path as firmware class only support one custom path inputted during boot time/load time. Unless to add new export function for firmware class. - if any typo on user level or file path not found, firmware class falls back to user helper interface. User is required to open another terminal to performs: -> echo 1 > loading -> cat capsule.bin > data -> echo 0 > loading Or wait for timeout. - User has the capability to configure the firmware_class time out value. If the infinite value is set, the only method to break the infinite waiting by manually perform "echo -1 > loading" on the other terminal. Are you guys okay with these trade off? Or you guys still okay with the previous 2 design idea? > > Alternatively, you can combine all the files into a cpio archive like > we do with the microcode loader too, and let the kernel parse the cpio > archive. I believe this will make the implementation complicated compare to above. Regards, Wilson ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
