Jordan, I agree that Nt32Pkg should be moved next to EmulatorPkg under Common. I will do that in V3 of this proposal.
DuetPkg is not Intel specific. It is generic package that layers on top of legacy BIOS. There is more than one vendor that produces systems with legacy BIOS. I got feedback earlier this this thread to reduce directory depth, so that is why VendorXYZ now appears directly below Platform. I then noticed there were platform packages that were not vendor specific and I added the directory name Common to hold those. I did consider moving them up a level, but that makes it more confusing to filter out packages that are not used with different PACKAGES_PATH settings. The use Vendor names instead of Arch names is on purpose at these levels. The Core, Drivers, and Common directories are not vendor specific but if they contain Arch specific content that is not vendor specific then the Arch directory names can be used, just like we do already in many modules/libraries today. There was a suggestion earlier to use an IA32X64 dir name for Ovmf and Duet, but that does not match the Arch names we already use, so it is creating a new one. That is why I through a more generic name like Common would be better. If anyone has a better name than Common, please let me know. You have a good question on the use of Arm. Is there a more appropriate vendor name for packages like BegalBoardPkg and Omap35xxPkg. Mike > -----Original Message----- > From: Justen, Jordan L > Sent: Thursday, May 26, 2016 1:38 PM > To: Kinney, Michael D <[email protected]>; [email protected]; > Kinney, > Michael D <[email protected]> > Cc: Ni, Ruiyu <[email protected]> > Subject: RE: [edk2] [RFC V2] Proposal to organize packages into directories > > On 2016-05-26 11:51:09, Kinney, Michael D wrote: > > Jordan, > > > > Is anyone still using UnixPkg? If not, then maybe it should be moved to > > Deprecated. > > > > I agree that Nt32Pkg functionality needs to be added to EmulatorPkg, but > > that is > > not what is supported today. Once that work is done, then I agree that > > Nt32Pkg > > should be moved to Deprecated. > > > > I would recommend NT32 just being moved under Common until it can be > merged into EmulatorPkg. > > I am bit confused about Common the other sibling dirs. For example, > should DuetPkg live in Intel? Instead of Intel/Arm, should the > directories follow the EDK II arch names? (IA32, X64, Arm, AArch64?) > > Also, rather than having a Common folder, was moving all the 'Common' > content up a level considered? > > > There could be other environments in the future that are not real HW, but > > are > > emulation or simulation of a UEFI/PI execution environments. That was one > > of the reasons I created an Emulated directory. If we think those could > > all go into Common or a Vendor specific directory in the future, then I have > > no issues with removing Emulated and moving EmulatorPkg to Common. > > > > I think it would still be better to make the architecture association > rather than 'Emulated'. > > -Jordan > > > > > > -----Original Message----- > > > From: Justen, Jordan L > > > Sent: Thursday, May 26, 2016 11:13 AM > > > To: Kinney, Michael D <[email protected]>; > > > [email protected]; > Kinney, > > > Michael D <[email protected]> > > > Cc: Ni, Ruiyu <[email protected]> > > > Subject: Re: [edk2] [RFC V2] Proposal to organize packages into > > > directories > > > > > > On 2016-05-25 19:03:38, Kinney, Michael D wrote: > > > > edk2 > > > > Platform > > > > Common > > > > DuetPkg > > > > OvmfPkg > > > > CorebootPayloadPkg > > > > Emulated > > > > EmulatorPkg > > > > Nt32Pkg > > > > UnixPkg > > > > > > UnixPkg has been replaced by EmulatorPkg. > > > > > > I think EmulatorPkg and Nt32Pkg should be moved under Common. > > > > > > EmultorPkg's name makes it clear what it is. > > > > > > NT32 should be merged into EmulatorPkg as another 'host' and then > > > deprecated. > > > > > > So, I don't think we need an 'Emulated' directory. > > > > > > -Jordan _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
