> On Sep 20, 2017, at 10:39 AM, Ard Biesheuvel <[email protected]> > wrote: > > On 20 September 2017 at 10:39, Ard Biesheuvel <[email protected]> > wrote: >> On 20 September 2017 at 10:34, Udit Kumar <[email protected]> wrote: >>> >>> When we want to have UEFI and OS accessing same media , >>> Possibilities I see >>> >>> 1- Patch OS For status check of media (diversion from generic OS), Good >>> case will be modify low level driver. >>> But we may end up some surprises on synchronization. >>> >>> 2- no runtime service for OS . I guess this will not be possible >>> >>> 3- Way the Vladimir implemented for eMMC, This has risk of losing data in >>> case of AC power off. >>> >>> 4- update hardware with dual view (Ard suggestion) >>> >> >> 5 - abstract direct block device access into a firmware service that >> is exposed via a DXE_RUNTIME_DRIVER. >> >> The UEFI spec allows you to expose entry points into a >> DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS >> can use a driver that uses the abstracted device rather than the real >> device. Performance is going to be terrible, probably, and lots of >> things that are specific to SD/MMC will no longer work, but it is a >> possibility nonetheless. > > BTW this would go beyond the UEFI spec, and would effectively be a > PI/UEFI dependent feature.
The concept of a runtime EFI driver is in the UEFI spec, but the issue is there is no way to tell the OS to not bind it's driver for that device that is universal. If you boot an unmodified OS it is going to conflict with the EFI runtime service. My gut feel is if the OS has a driver for the device it may be better to make the media format the architectural point. That way the OS can read/write it via a driver/app. There could be an UEFI Services Table entry that implies what scheme is being used. That way there is only every one owner of the hardware device. I assume #3 is like this? Thanks, Andrew Fish > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
