On 05/08/16 13:19, Chang, Abner (HPS SW/FW Technologist) wrote: >>>> What would prevent this from living under OvmfPkg? Say >>>> OvmfPkg/OvmfPkgRiscV64.dsc?
> I think it should be no problem to use OvmfPkg as common > processor/platform emulator. Just you still can see few Intel things. > ARM QEMU implementation must be considered as well if we move RISC-V > to OvmfPkg, thus we can have the consistent implementation. RISC-V > QEMU implementation just follows ARM QEMU implement, that is to have > a separate package. But I agree with you that all > processors/platforms emulator should be under OvmfPkg. I strongly disagree with this. Although OvmfPkg currently contains both platform-specific modules (for Ia32 and X64), and a number of reusable, platform-independent modules, it should not be considered a grab-bag of guest platform code for any and all hypervisors (and their various targets). ArmVirtPkg has always been separate, despite being "just another" upstream QEMU target. It has worked splendidly. Xen support lives right under OvmfPkg, and it has worked terribly. It all comes down to maintenance. Maintainers in edk2 are assigned to top-level Pkg directories. If you introduce Risc-V virt in a separate top level package, and become its maintainer, I welcome that with open arms. If you try to push Risc-V stuff under OvmfPkg, which will make me responsible for reviewing patches and fighting regressions for the sake of a platform I have no interest in, I will definitely block that. ISA- and platform-specific modules live in separate directories in all of the projects I can think of as examples. QEMU? Check. The kernel? Check. Inter-mixing within a module is done only if the customization is minimal. (There are a few examples in OvmfPkg, and I dislike them.) If edk2 elects to introduce a finer (= subdirectory- and file-level) granularity to Maintainers.txt, *and* we can carve out a well separated directory structure for RISC-V under OvmfPkg, then maybe I could be convinced. For example, this *too* has worked perfectly well under ArmVirtPkg. In ArmVirtPkg the separation between Xen and QEMU is utterly clear (thanks again Ard!), and I immediately know if a quick skim and an Acked-by are enough from me, or I need to dive in and spend a week or more on reviewing patches. Regressions are terrible if they affect the code that I run, while they are "meh" *for me* if they affect Xen. (This is not to say that Xen should be ignored. Instead, it means that Xen people should delegate their own full-time edk2 maintainers, and we should assign them with the right granularity in Maintainers.txt. This happens to work very well in ArmVirtPkg, where we informally follow such a subdivision with Ard.) Thanks Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
