On 20/04/2023 13:54, BALATON Zoltan wrote:
(cut)
In case you decide to change your mind or somebody else can step in as a maintainer to more sensibly manage this project, my ideas for improvements that I'd consider to elaborate on would be:
- Finish this pci method simplification by moving some more methods to Forth
I've already answered this one.
- Implement missing register access words to get FCode ROMs working
Segher already replied to this, explaining how the implementation should call the associated FCode tokens. I don't believe there has been another version of the patch submitted that addresses his comments?
- Get rid of fw_cfg and hard coded machine parameters and pass an FDT from QEMU
instead as done my spapr and SLOF or pegasos2 and VOF; I've already ported SLOF's FDT parser to OpenBIOS but because it's impossible to convince you I did not finish this. This would simplify arch/ppc/qemu a lot by removing hard coded device trees and lift the need to change OpenBIOS together with QEMU as then device tree changes could be made in QEMU alone. For example fixing G5 mac99 can be possible without any change in OpenBIOS and thus lessen maintenance need for OpenBIOS.
When I asked how this would work with the device trees already included in OpenBIOS, in particular i) how you would bind Forth words into the device nodes in the FDT and ii) how this would work for non-QEMU builds without duplication there was no follow-up proposal.
(Related to this is passing VGA driver through ROM to lessen dependency on fw_cfg as a first step and move towards real FCode ROM as it works on real hardware so instead of hacks do what real hardware does. But that's another change that met resistence from you.)
As already explained on the QEMU list, the problem here is that the NDRV binary can only be built within a classic MacOS guest which means you would end up with the problems of distributing a binary blob from an external project. Since QEMU already has a mechanism to support this, it makes sense to leverage that via fw_cfg injection into OpenBIOS to avoid a dependency problem, which was also the intention of the original author (Ben).
I could try to explain the ideas in more detail but if your first reaction is just that you don't think this can be a good solution then even spending time with detailing the ideas is wasted time so I'll just stop now.
I've replied to your points above for completeness, since your representation above is misleading and implies that I am neglecting my role as maintainer. There is nothing wrong with having ideas as to how the project should proceed, but as you see above these ideas were often missing follow-up patches or critical detail. And one of the roles of a maintainer is to point out such problems before anyone invests a significant amount of time or effort to avoid disappointment.
Finally your comments about holding the project hostage are completely unacceptable: if a maintainer points out problems with your ideas or patches, it is not because of a whim but because there is a good reason e.g. the PCI bus id patches were refused because they broke booting NetBSD. If you find that you are constantly fighting with maintainers when proposing ideas and/or patches, I can only suggest taking some time out for a period of introspection to try and understand why this is the case.
ATB,
Mark.