Messages in this thread | | | From | "Kweh, Hock Leong" <> | Subject | RE: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface | Date | Mon, 2 Mar 2015 10:59:00 +0000 |
| |
> -----Original Message----- > From: Borislav Petkov [mailto:bp@alien8.de] > 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
| |