On 2016-05-09 08:31:38, Laszlo Ersek wrote: > 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. >
My opinion on this is reversed. I wish more effort had been made to have arm-virt in OVMF, and I can't see how splitting Xen out to separate packages would have helped. > 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. > I think we should alter Maintainers.txt to work best for the tree rather than having the tree bend to Maintainers.txt. My main concern about Maintainers.txt is adding too many committers. Maybe we could add a reviewer level for people that can review for a package, but not commit. They can review and prep branches/patches for the maintainers to fetch and then push. In this case, maybe a RISC-V reviewer would work well for OVMF... I also note that ShellBinPkg seems to have some arch specific maintainers. -Jordan > 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
