On 2014-12-18 06:48:09, Olivier Martin wrote: > ARM's implementation was initial done by a summer student (Brendan). > I asked him to implement a file system on top of FV to be able to > start Android Fastboot UEFI application located in a FV from BDS. > He quickly wrote a first implementation. We later refined his > implementation to fix some issues and be more conformant with the > UEFI spec. > > I do not remember the full details of the story but we were aware of > Colin's work. Maybe we knew it before Brendan started his work or we > discovered it a bit later. > I asked him to evaluate Colin's solution. In his own words: "looks > like it's probably better than FvSimpleFilesystemDxe". So maybe we > kept FvSimpleFilesystemDxe because we wanted it to be part of the > EDK2 repository as our reference implementation would rely on it and > we did not add a requirement on pulling external repositories.
Actually, there is no good reason that Colin's version never made it upstream into EDK II. In fact, this has been my plan since he completed the project. (But, clearly I had plenty of time, and I failed to follow through.) I believe Colin did the work having agreed to the old "TianoCore Contributor Agreement" back before we had the "Contributed-under" clause. (Maybe Laurie can confirm?) I've thought about getting his version upstreamed many times over the years, but I never got around to it. The change in contribution process since then also complicates things a bit. I had been thinking of asking Colin to resubmit it with 'Contributed-under', but then I saw your contribution... If there is a technical reason to prefer either, then we still have a choice. Regarding Colin's FfsDxe, I confirmed that it was capable of loading and running either the EFI Shell, or the UEFI Shell. I did not try to load an OS boot loader. > Anyway, just to say the EDK2 repository should be more open to > external packages in the sense they should be part of the > repository. There are few useful contributions floating around such > as file systems support (Ext2, etc), platform support (BeagleBoard > black, Pandaboard, etc), driver support, google summer of code > projects. These projects would have a better visibility and support > if there were part of EDK2 source tree. That would also avoid people > to duplicate work. Including these projects would also bring more > contributions/fixes to the core EDK2. I think you make a good point. The latest update to Contributions.txt at least allows for some new source licenses... Maybe it is a small step in the right direction? I think UDK drives certain packages to be more conservative, but there are plenty of non-UDK packages in EDK II. -Jordan ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
